没有数据库映射的对象持久性

Question

I am looking for an advice on persisting Java objects without the need for database mapping. In simple (and silly) words I want to have JPA, but not be bothered by details of database structure: tables, columns, keys. Ideally what I would like to achieve is just defining Java classes, instantiating objects and persisting/retrieving these objects and their associations without any need for repeating entities/properties information anywhere else. I know that there are various kinds of NOSQL databases, document databases, key-value storages and so on, but I have close-to-zero experience with anything other than flavors of RDBMSes and by simply reading descriptions and manuals of Cassandra, BerkeleyDB, MongoDB etc I am even unable to judge whether they support my use cases or not ;( So here are my requirements:

• I am going to use Java programming language, so it would be nice if there were some JARs with API to access database
• My main goal is to avoid the need of defining an object-to-table mapping, as I see it superfluous and I consider the type definition as the only necessary source of metadata for persistence. Anything more is too much, maybe except some properties for fine-tuning (converters, transient fields, etc.) So if there is some JPA/RDBMS based solution that would let me completely avoid touching database schema, I take it.
• Object graphs in my application are going to have many relationships, there is going to be no logical top-level object which aggregates other sub-objects as fully contained properties. On the contrary, my model contains quite a few top level classes, which will be referenced more or less directly by other types with one-to-many and many-to-many associations. For this reason I guess that semi-structural, document-based and JSON-based storage (CouchDB, MongoDB) won't suit my needs, as I could not find the way of easily expressing relationships between objects (ie documents) other than aggregation. Or I am just wrong.
• Number of persisted objects is going to be 'average', ie there is no need for particular massive scalability, big-data functionalities etc. I'd estimate a number of objects as hundreds of thousands.
• I need the storage to be transactional, with commit on success/rollback on error mechanisms or equivalent.
• Schema evolution should not require any operations on underlying storage schema. So when my model changes, all I want to do is retrieve object, modify/recalculate properties, and store modified object. No need to change any tables, columns, etc.
• I would need to execute some queries based on object properties. Not really complicated ones, with just regular relational operators, but possibly with joins ( FROM Book b WHERE b.price < :allowedPrice AND b.author=:author ).
• As it is going to be used in my hobby, eventually-to-become-commercial, project, Id'd like it to be free for commercial use (ideally), or with some non-restrictive licensing for as long as it stays an after-hours thing (and this might be ages ).

Actually from what I have read, it seems that some object database would be the best choice for me, for example DB4O or ObjectDB. Unfortunately, DB4O is dead, and license for ObjectDB seems to be a bit too demanding for me. Maybe there are some possibilities I am not aware of to fulfill above requirements with something else, some NoSQL solution or some set of tools on top of 'regular' RDBMS.

Do you have any suggestions or advice?

Answer 1

I decided to focus mainly on object DB solutions, and unfortunately I could not find many of them. I evaluated ObjectDB and I have to admit that it's the best persistence solution I happened to work with.

Pros:

• It supports both JPA and JDO APIs, so using OBjectDB is just as easy as using any ORM-based solution. If you know JPA or JDO, you have no entry cost for starting with ObjectDB. If you stick to some really basic guidelines, you can switch between ObjectDB and ORM almost at will, just by changing connection string and deployed JARs.
• ObjectDB does what almost none of persistence libraries does: it let's you focus on persistence task without any disturbances and inconveniences caused the underlying storage. You define your model just once, as entity classes, and you do not need to repeat yourself and handle any tables, columns, ORMs ( orm.xml , be gone!), DB schema evolution, moving data between column on schema updates...
• ObjectDB has more relaxed requirements than JPA ORM. You can persist objects of almost any type (GUIDs, new Date and Time API!), you need fewer annotations (for example, relationship annotations, ie @OneToMany , @ManyToMany and others) are not required. However you still need them if you need source compatibility between ObjectDB and JPA ORM.

Cons:

• It's a commercial product, and as such it requires you to get a license. It's possible to use ObjectDB for free (commercially or not), but only for up to 10 entity classes. Sometimes it might be possible to get free, unlimited license for evaluation purposes - or at least there used to be such information on ObjectDB page, but I do not know if it's possible now - I did not ask.
• While JPA seems to be almost fully supported, static metamodel API is not. There is no static metamodel generator, and even when you'd create it by hand, criteria API methods with metamodel arguments throw Not Supported exception. It might be an obstacle if you'd plan to switch from existing solution (for example, Hibernate) to ObjectDB. Hopefully support for static metamodel will be added some time in the future.

For me, ObjectDB seems to be exactly what I need, and I will evaluate it further to check other aspects, as performance, conformance to more obscure corners of JPA and possibility of easy replacement with ORM when needed, schema evolution, etc.