Here's the scenario: I have an open source library called Informa which uses Hibernate for it's persistence layer. (It's an RSS library but that doesn't matter.)

The users of my library (apps that call Informa, call them client apps) have additional information that needs to be persisted, much of it associated with existing Informa/Hibernate objects, some not.

Here are the choices I can think of:

1. Use a different, non Hibernate scheme in the client apps. The library saves its state via Hibernate and everything else is saved elsewhere. There are many problems with this, it is inelegant and hard to make work reliably.

2. Use hibernate in the client apps, but a separate hibernate schema and a separate sql db. Figure out how to make transactions across both dbs to ensure consistency. This is better but still not elegant. But it does maintain decoupling between library and client app.

3. Use hibernate and somehow store the client apps records in the same database. This would be cool but seems hard because the schema of the database somehow has to combine info from both the library and the client app.

4. Build 'extensibility' into the library's schema. Essentially allow the client app to put references to its custom objects into a field of the existing libraries objects called something like 'client info.' The client could gen up the right objects and attach them to the appropriate library object and have them be persisted right along the library objects by informa. Make sure that the attached client info objects are serializable.

Does this analysis make sense? Did I leave any out?

(4) seems the best to me, but I don't know how to build it with Hibernate.

Thanks.

Pito