For those of you interested in Object - Relational Mappings:
I'd like to announce the newest release of ObJectBridge.
It's OpenSource, it's 100% Java, it's based on InstantDB.
See http://objectbridge.sourceforge.net for more infos.
>From the release notes:
ObJectBridge -- Bridging Java Objects and Relational Databases
ObJectBridge (OJB) provides transparent persistence
for Java Objects against relational databases.
It consists of a generic PersistenceBroker and an ODMG 3.0 compliant
OJB uses an XML based dynamic Object - Relational Mapping. The mapping is
configurable on a per class basis and allows lazy materialization through
virtual proxies. OJB supports Bean Managed EntityBeans (BMP). It's
proxy- and caching-strategies allow performance enhancements for EJB
The 0.1.83 release of ObJectBridge includes the following modules:
broker -- transparent persistence for Java Objects
server -- ODMG 3.0 compliant Objectserver (work in progress)
test -- JUnit regression tests and examples demonstrating programming
examples -- sample code demonstrating the API, (e.g. usage in EJB scenarios)
changes in this release:
- Support for user defined collections. It is now possible to use user
(e.g. typed collections) as Collection attributes. These collections must
implement the interface ojb.broker.ManageableCollection to provide minimum
interoperability with the PersistenceBroker mechanisms. There is a new
TestClass test.ojb.broker.TypedCollectionTest testing and demonstrating
- There is a first fully functional ODMG Collection:
Dlist. It's implemented by ojb.server.collections.DListImpl. There is a
TestClass test.ojb.odmg.DListTest testing and demonstrating the usage of
- Complete redesign of the ODMG Transaction-mechanism. I unified the
David's TransactionWrapper objects with my idea of ObjectModification
objects, that had been responsible for different aspects of the
management in OJB.
- Removed interface IPobject and baseclass Pobject. These
were meant as examples for encapsulating PersistenceBroker code in
objects. I don't want to encourage such a poor design any longer...
- Collection attributes can now be defined without reverse
This design was based on the wrong assumption, that there is always a
ReferenceAttribute describing the foreignkey relation betweeen the
tables. Now Collection Attributes can be defined without specifying an
inverse reverse ReferenceAttribute. To make this possible it's now
to specify the list of foreign key attributes (respectively their
Ids) within the CollectionDescriptor.
- Harmonized the syntax for ReferenceDescriptors and CollectionsDescriptors
in the repository.dtd. Now , , can
be used in both classes. Usage of these tags is now optional. If
is ommited, true is the default value. If ,
default value is false.
- storing of collection attributes did not work due to an error during the
last refactoring. No JUnit test detected the error
Thanks to Sascha Koenig for reporting this bug.
To unsubscribe from this mailing list, send email to firstname.lastname@example.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at email@example.com.