Why OJB, why yet another O/R mapping tool?

here are some outstanding OJB features: It's fully ODMG 3.0 compliant It will have a full JDO implementation It's higly scalable (Loadbalanced Multiserver scenario) It provides multiple APIs: The full fledged ODMG-API, The JDO API (planned) and the PersistenceBroker API. This API provides a O/R persistence kernel which can be used to build higher level APIs (like the ODMG and JDO Implementations) It's able to handle multible RDBMS simultaneously. it has a slick MetaLevel Architecture: By changing the MetaData at runtime you can change the O/R mapping behaviour. (E.G. turning on/off usage of Proxies.) It has a simple CacheMechanisms that is fully garbage collectable by usage of weak references. It has a simple and clean pattern based design. It uses a configurable plugin concept. This allows to replace components (e.g. the ObjectCache) by user defined Replacements. It has a modular architecture (you can quite easily reuse some components in your own applications if you don't want to use the whole thing: The PersistenceBroker (e.g. to build your own PersistenceManager) The Query Interface as an abstract query syntax The OQL Parser The MetaData Layer The JDBC Accesslayer It has a very sharp focus: It's concerned with O/R mapping and nothing else. Before making OJB an OpenSource project I had a look around at the emerging OpenSource O/R scene and was asking myself if there is really a need for yet another O/R tool. I came to the conclusion that there was a need for OJB because: There was no ODMG/JDO compliant opensource tool available There was no scalable opensource O/R tool available there was no tool available with the idea of a PersistenceBroker Kernel that could be easiliy extended The tools available had no dynamic MetaData architectures. The tools available were not as clearly designed as I hoped, thus extending one of them would have been very difficult.

Does OJB support my RDBMS?

please refer to this document.

How to use OJB with my RDBMS?

please refer to this document.

How to page and sort?

Sorting can be configured by ojb.broker.query.Criteria::orderBy(column_name). There is no paging support in OJB. OJB is concerned with Object/Relational mapping and not with application specific presentation details like presenting a scrollable page of items. OJB returns query results as Collections or Iterators. You can easily implement your partial display of result data by using an Iterator as returned by ojb.broker.PersistenceBroker::getIteratorByQuery(...).

What about performance and memory usage if thousands of objects matching a query are returned as a Collection?

You can do two things to enhance performance if you have to process queries that produce thousands of result objects: Use getIteratorByQuery() rather than getCollectionByQuery(). The returned Iterator is lazy and does not materialize Objects in advance.Objects are only materialized if you call the Iterators next() method. Thus you have total control about when and how many Objects get materialized! You can define Proxy Objects as placeholder for your persistent business objects. Proxys are lighweight objects that contain only primary key information. Thus their materialization is not as expensive as a full object materialization. In your case this would result in a collection containing 1000 lighweight proxies. Materialization of the full objects does only occur if the objects are accessed directly. Thus you can build similar lazy paging as with the Iterator. You will find examples in the packages test.ojb.broker The Perfomance of 1. will be better than 2. This approach will also work for VERY large resultsets, as there are no references to result objects that would prevent their garbage collectability.

How is OJB related to ODMG and JDO?

ODMG is a standard API for Object Persistence specified by the ODMG consortium. JDO is Sun's API specification for Object Persistence. ODMG may well be regarded as a Precursor to JDO, even some of the original ODMG participants are working on the JDO specification. I assume JDO will have tremendous influence on OODBMS and RDBMS vendors to provide compliant products. OJB currently contains of two main APIs: A generic PersistenceBroker which provides a minimalistic but (mostly) sufficient API for handling Object Persistence against relational Databases. The PersistenceBroker also provides a scalable multi-server architecture that allows to used it in heavy-duty app-server scenarios. An ODMG Implementation build on top of this broker. ODMG (www.odmg.org) is an API specification for Object Persistence. It may be regarded as a forerunner to JDO. In fact JDO incorporates many ideas from ODMG and several people who have been involved in the ODMG spec are now in the JDO team. When I started OJB, JDO was in a very early alpha stage but ODMG was there in a mature and widely accepted 3.0 version. Thus I choose to start with an ODMG Implementation. One of my aims for OJB is to provide a JDO implementation too. This JDO implementation will be a very thin layer above the existing OJB stuff of PersistenceBroker and ODMG implementation. There are several things in my ODMG implementation (e.g. the Lifecycle concept) that have been designed with JDO in mind!

What are the differences between the PersistenceBroker API and the ODMG API? Which one should I use in my applications?

The PersistenceBroker (PB) provides a minimal API for transparent persistence: O/R mapping Retrieval of objects with a simple query interface from RDBMS storing (insert, update) of objects to RDBMS deleting of objects from RDBMS This is all you need for simple applications as in tutorial1. The OJB ODMG implementation uses the PB as its persistence kernel. But it provides much more functionality to the application developer. ODMG is a full fledged API for Object Persistence, including: OQL Query interface real Object Transactions A Locking Mechanism for management of concurrent threads (apps) accessing the same objects predefined persistent capable Collections and Hashtables Some examples explaining the implications of these functional differences: Say you use the PB to query an object O that has a collection attribute col with five elements a,b,c,d,e. Next you delete Objects d and e from col and store O again with PersistenceBroker.store(O); PB will store the remaining objects a,b,c. But it will not delete d and e ! If you then requery object O it will again contain a,b,c,d,e !!! The PB keeps no transactional state of the persistent Objects, thus it does not know that d and e have to be deleted. (as a side note: deletion of d and e could also be an error, as there might be references to them from other objects !!!) Using ODMG for the above scenario will eliminate all trouble: Objects are registered to a transaction so that on commit of the transaction it knows that d and e do not longer belong to the collection. the ODMG collection will not delete the objects d and e but only the REFERENCES from the collection to those objects! Say you have two threads (applications) that try to access and modify the same object O. The PB has no means to check whether objects are used by concurrent threads. Thus it has no locking facilities. You can get all kind of trouble by this situation. The ODMG implementation has a Lockmanager that is capable of synchronizing concurrent threads. You can even use four transaction isolation levels: read-uncommitted, read-committed, repeatable-read, serializable. In my eyes the PB is a persistence kernel that can be used to build high-level PersistenceManagers like an ODMG or JDO implementation. It can also be used to write simple applications, but you have to do all management things (locking, tracking objects state, object transactions) on your own.

what are the OJB internal tables for?

please refer to this document.

When is it helpful to use Proxy Classes?

Proxy classes can be used for "lazy loading" aka "lazy materialization". Using Proxy classes can help you in reducing unneccessary db lookups. Example: Say you load a ProductGroup object from the db which contains a collection of 15 Article objects. Without proxies all 15 Article objects are immediately loaded from the db, even if you are not interested in them but just want to lookup the description-attribute of the ProductGroup object. With a proxy class, the collection is filled with 15 proxy objects, that implement the same interface as the "real objects" but contain only an OID and a void reference. Once you access such a proxy object it loads its "real subject" by OID and delegates the method call to it. have a look at the ProxyExamples in test.ojb.broker for the source code of this example.

How can I convert data between RDBMS and OJB?

For Example I have a DB column of type INTEGER but a class atribute of type boolean. How can I provide an automatic mapping with OJB? OJB provides a concept of ConversionStrategies that can be used for such conversion tasks. Have a look at the respective document.