I have an interesting project :

For phase 1, I have to reengineer some existing code that uses a Sybase database. The schema will likely change, so Hibernate seems like an ideal way to minimize how that will impact me.

For phase 2, I will have to stop using Sybase and instead switch to using a *proprietary* in-house, non-SQL, "OOP-like" database for which there is obviously no current Hibernate adaptor.

My crazy thought is that if I could write the code to allow Hibernate to talk to this new OOP db (it has a well-documented API), that I could again minimize the impact on the code I'm currently rewriting. But I have 2 big questions:

1. Am I nuts? Is it hard to write a new "dialect"? I can't seem to find any info on how to extend Hibernate in this way. Or is Hibernate ultimately designed for a SQL-friendly persistence layer?

2. How does the LGPL license affect me in this case? Since the DB is effectively a "trade secret", I can't extend Hibernate if in so doing I will have to release this code to the general public (not that it would do anyone any good: this DB only exists at my firm).

All comments appreciated

If you really try to do this, expect an ammount of effort close to a rewrite. Hibernate is an object relational mapper, and we have no motivation to support anything else.

besides agreeing with Michael then i have the following:

1. Hibernate is built to work on SQL based databases

2. Hibernate does have support for CustomPersisters and CustomCollectionPersisters which does allow basic persistence for non-sql based persistence (read: you can load/save stuff, but you probably can't query for anything)

3. regarding license i don't think you have a problem as long as you program against the interfaces of hibernate (meaning e.g. extending custompersister etc.) ... but if you need to make changes to the internals of hibernate and its interfaces to make it work you will need to allow access to that sourcecode as par the LGPL license. (at least from my understanding ;)

LGPL licensing is really easy to understand: Use the binaries you downloaded and don't worry. As soon as you build (and distribute) your own binaries, you should ask yourself if you made modifications that have to be made public.

My understanding is that "public" does not mean within our own firm. So if I modify source for internal purposes only, that does not need to be released.

Querying won't work without a complete re-write of the QueryTranslator *and* anything that depends on it (e.g. the Loader). The QueryTranslator is designed to work with JDBC - it produces an SQL statement and other information that allows parameter binding. Since I've just built a new QueryTranslator using ANTLR, I think I can say that this is definitely not a weekend coding project.