Michael Bayne
66952dc472
It was a constant source of annoyance that part of the Depot implementation lived in samskivert.jdbc. Now it all lives in Depot and samskivert can go back to being a long obsolete library of utility methods. Depot clients will have to make three renaming changes: 1. ConnectionProvider &c are now in com.samskivert.depot. 2. ByteEnum is now in com.samskivert.util. 3. Methods that returned index information used to return samskivert Tuple if you wanted an expression and an order. Now they must return Depot Tuple2. This should fail at app startup if you miss a spot, so this should not result in any ticking timebombs. NB: the next commit is probably going to change Tuple2 into a proper named class because using a Tuple2 for this situation turns out to suck. NB2: I moved DropTableMigration out of impl and put the impl details into DepotMetaData. I should have done that separately, but it was already in progress when I undertook to revamp.
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/