Michael Bayne
872b2d9ef3
It's not clear what the right thing to do is if the database connection fails
during the middle of a transaction. In general, one can't talk to the database
after that, so I'm assuming the transaction is aborted (or eventually aborted)
and rolled back, and everything has to be retried.
I'm not currently tracking state inside a Transaction, which means that I don't
freak out if you call commit() then call rollback(), I just ignore the latter
call, and it's also possible to do something stupid like:
Transaction tx = Transaction.start(ctx);
try {
_somRepo.doOp(..);
} catch (DatabaseException de) {
// no problem!, keep on keepin' on
}
_someRepo.doAnotherOp(...);
tx.commit();
If the first repo op fails due to a database connection failure, the
transaction will get a new database connection for the second op and do the
last half of the op in a new connection.
I guess I'll have to do some state tracking, because stupid as the above code
is, I'm sure some circumstance will arise where it seems like a reasonable
thing to do, and hilarity will ensue. Blah.
Depot Persistence Library
Depot is a relational persistence library for Java. It is an ORM library, but has aims that are somewhat different from the popular "managed" persistence libraries like Hibernate and others.
Design Goals
- Eliminate (as much as possible) the use of raw SQL, instead providing Java classes that allow the expressions of queries and updates in as concise but compile-time checkable a manner as possible.
- Reduce the pain of schema and data migrations as much as possible, but not so much that the system used to do the migrations is too complex for anyone to understand or use properly.
- Use annotations to layer database metadata over the top of (almost) POJOs.
- Use annotations that are syntactically and semantically equivalent to EJB3 persistence annotations wherever possible.
- Support multiple database backends (currently MySQL, Postgresql and HSQLDB).
- Provide caching support (currently integrated with EHCache).
- Keep an eye toward eventual support for sharded databases (not yet implemented).
Depot studiously avoids ever doing anything magical. You only access the database when you make a method call requesting that records be read from the database or records be updated in the database. Depot attempts only to be a concise, compile-time checkable veneer over raw database access that conveniently models database tables as Java objects.
In this way Depot is more of an evolution of DAO-like libraries of the past than a pared down sibling of the managed persistence libraries of the present. It distinguishes itself by taking advantage of annotations to concisely express database metadata and by striving to stay out of your way as much and surprise you as little as possible.
Code Examples
Here's are some example to give you a taste of what code using Depot looks like.
- A simple code example
- Various example queries
API docs are also available.
Features
Depot supports a number of very useful features. Here are a few of the main features for which time has permitted documentation:
Getting Started
If you want to use Depot on your project, check the following page for information on getting Depot and dependencies via Maven or manually, as well as what sort of configuration Depot requires to start talking to your database.
- Configuring and integrating Depot with your project
Discussion
Feel free to pop over to the OOO Libs Google Group to ask questions and get (and give) answers.
History
Depot was started in September of 2006 by Three Rings as a part of their Whirled project. Its primary authors are Michael Bayne and Pär Winzell.
License and Distribution
Depot is released under the New BSD License. The most recent version of the library is available at https://github.com/threerings/depot/