BRIEF
The BeNOW repository API is a smart and flexible object/relational mapping layer. It allows for near-automatic persistence of Java object with relational (JDBC - firebird, mysql, etc) database backends and object level querying. There should be no need to touch SQL at all when using the mapping api, as all schema, queries and population are done automatically. It makes database backed Java programs very easy. Here's a quick overview of the features.

DOWNLOAD
benow-repository.nightly.tar.gz - nightly checkout from CVS

DOCUMENTATION
API documentation is available online or within the bundle.

TECH
Repository api uses the following

• java 1.5 , log4j
• BeNOW security, java, util and xml projects

FEATURES
Auto schema generation. Schema for tables, indexes and generators is generated automatically from the object model. There are no mapping files needed... no files to get out of sync. The mapping (which guides persisting, fetching and querying) is automatically generated at runtime. Object schema is regenerated when an objects version (serialVersionUID) changes, transparently, if possible.

Schema tuning. Schema can be tuned to have the generated schema resemble what it would be if you were to do it manually... ie optimal. Tuning includes hinting to minimize joins, field size, ignored fields, etc.

Persistence of simple and complex types. Accommodations are made for all the simple and more common java types (String, int, Integer, double, long, File, URL, Class, etc). Complex objects (objects composed of one or more simple and complex types) can also be persisted. Linking between objects is automatically managed.

Easy Object navigation. Navigating persisted Object networks is easy, with only a single one-line addition required to ensure linked object population.

List management. Linking from one object to many others is facilitated. Persistence operations are automatically performed when adding or removing from a list within a persisted object. Persisted lists may be partially retrieved (ie fetch 25 from position 50) to allow for high performance via paged results.

All java constructs managed. The API understands Abstract and Interface field declarations, persisting and reconstructing the full class instance. Abstract and Interface fields are fine for single field and lists. It adds a slight performance overhead, but, basically, you don't have to code as if you were going to a database... you can use the full expression of java. Java reflection is used throughout and private/protected field population is supported, which again means that you don't have to sacrifice the object model for persistence.

Use tuning. Get and set methods can be defined so as to do any processing before getting or setting a field. Gets and sets allow for transient field (ie caches, index) population, validation, etc. Fields can be defined as Required, which causes them to be fetched when the container object is fetched... no need to explicitly fetch for common relationships.

Object level queries. Querying is done at the object level... asking for a class with certain field values, ordering, etc. Low level SQL is available for more complex operations, however you have to maintain correct SQL.

Easy integration with XML. Via the BeNOW XML API it is possible to move Objects to and from XML very easily. While not directly related to the repository api, it allows to easily move from persisted (sql) to interchaged (xml) data.

Notification. Applications may subscribe to receive notification on repository operations... when an object of a certain class is changed, added, deleted, etc. Such notification allows integration with caching systems, etc.

Plays well with others. As the constructed schema is quite effective and the backend databases are standard, it is very easy to share the backend among applications, or to perform traditional sql data maintenance, etc. There are some fine free databases out there, with some fine management and end user applications... you don't have to give that up to talk objects.

Speedy to run and develop with. While not completely optimized, the repository is still quite speedy. As the developer is free to work at the object level, they don't have to slow down to write and maintain SQL, resulting in much more application level work being done, which is less tedious and more fun.

Modular. The API is designed in such a way that implementing storage ability for differing backends (custom sql, oodbms, serialization, etc) is quite easy. The backend can be switched programatically, so that applications don't even require recompilation to move to another database backend.

WHY?
Why this over alternatives (hibernate, oodbms, JDO implementations, etc)? Well, this is lighter, and quite easy to use. It allows for tight control over generated schema and is designed to compliment the already excellent RDBMS's, not to replace them. This began as a wrapper around Castor JDO, but Castor tried to do too much and was slow and hard to fix when needed. I decided to rewrite it and it turned out to be much faster, much easier and less complicated.

USE IT!
Specific installation and use instructions are included in the download (if you're lucky), as is javadoc documentation.

The repository API is a core component to many ongoing applications. Give it a try. I like it. It's licensed as LGPL, so use it with your open applications. Please let me know if you have any support questions or comments. I am available for contracted extension should you wish further (large scale) extensions to the API. If you use it and like it, please consider making a donation.