I've always felt that SQL is a poor match for object persistence; something of an unnecessary protocol layer. With the Criteria API, it seems that it's possible to use Hibernate without ever writing a single line of SQL.
Would it be possible to couple Hibernate with BerkeleyDB (libdb3)? BerkeleyDB offers ACID-compliant log-based transactions, cursors, and rollback. Everything basically revolves around joins and cursors on two-column tables where each column is an opaque byte sequence. It's very, very fast. It also runs in-process (JNI, not sockets) in multiple cooperating processes if necessary (not really relevant in a JVM scenario I suppose). Basically it's the storage manager ripped out of a serious database. How realistic is this? It shouldn't be too hard to fake up ResultSets; basically you'd be writing the skeleton of a JDBC driver minus the executeQuery() and executeUpdate() methods, and then translating Criterias directly into BerkeleyDB API calls. With Hibernate's small size, this would make an interesting platform for resource-constrained environments where the footprint of simply implementing complete support for SQL knocks most databases out of the game. It also makes embedding a database into your app (think client-side apps here, not server-side) much more palatable. - a -- Thin UI's done right -- http://www.xwt.org/ ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
