What do Java game developers use for Database persistence?

Hi All,

I’ve been hacking at a game for a while and I need a fair amount of data so I use SQLite and store it. Using JDBC directly is somewhat tedious and I was wondering if anyone had any good ORM type libs they recommend for use for games or smallish apps.

I’ve looked at Hibernate but it’s huge and over complicated for my needs.

Thoughts?

TIA

sounds like mybatis could be the right tool for you.

What we need is something that can automaticlly convert a class into a record in a table, matching field’s value and type to table’s colomn. That already is available on MVC frmaework such as Play!, but I see no one yet for desktop use.

Yeah I see what you mean. Most ORMs are more complex than they need to be for basic usage.

The closest I found is Persist (http://code.google.com/p/persist/) but it’s not well maintained and it has it’s fair share of quirks.

I’ve been hacking around with various solutions and so far found nothing that I like yet. I see what you mean by Play framework - something could be adapted from it.

This is a fairly easy task using reflection. You can pretty much just drop a class and its fields/values into an sql command.

Hi Otto,

Even MyBatis seems too complex. If (eventually) I need to port to a smaller device - the smaller the library the better.

Let me mull this over for a bit.

I had done it before, but that’s not reliable. On Play!, you just let the will-be-persisted class to extends Model and call save() like playerData.save() to persist. The framework will take care everything including table creation. If in next day you add more field, it will also update the schema for you. That’s most simple DML related operation that I ever use.

Interesting but this is also a huge framework 90 MEG! On server side applications size is not so important. For smaller apps and Games we need something tiny that just does the job with little or no dependencies.

Yeah, if only we could find a way to just rip off that Model library. However it needs other dependencies inside that 90MB.

Play 2.0 uses Ebean for Java and Anorm for Scala. They’re both available separately.

Ebean: http://www.avaje.org
Anorm: http://repo.typesafe.com/typesafe/releases/play/anorm_2.9.1/

There’s also Siena, another AR type thing: http://www.sienaproject.com/index.html

I use MyBatis.
Pretty simple to use.
Pojos with SQL defined in XML and/or in annotations.
Can’t speak how it deals with more complex requirements - I only save players and scores so far.
In compound with JavaDB there is an issue with setting null values, so I might change to HSQLDB.
Overall it is definitely worth a look.

(Theses configuration was not always useed for games but for my projects in general)

Database + Persistence Layer : H2 + Hibernate (for larger project that fit he need of an SQL langage)
Database + Persistence Layer : Cassandra + Custom persistence layer (for servers that just need to store some simple data structures)
Database + Persistence Layer : Serialization + Custom persistance layer (for small games)

Thanks that’s interesting.

Siena is what I meant. Beside save() there are useful static method such as find() and fetch(). Thanks for find it.

This is a lot of good info. Thanks guys.

I have some code for this I’ve been working on as well. I have some vacation days so I was thinking of putting it together.

It does not require any mapping, instead it uses auto-discovery and convention over configuration to figure out table and column names.

If I get something and post a link would anyone be interested in trying it out? Maybe I could have something in the next week or so.

You can post it on Shared Code section.

You can also do it the other way around - generating record classes from a db-schema. I had some good experience with JOOQ

Yeah JOOQ is interesting but really it emphasizes the query. In many situations especially with games we don’t have any complicated queries to worry about. Really I’d prefer just a simple Java Bean and a quick and easy way to read and write it.

I used to insist on using a really “proper” O-R mapper so that JPA or JDO were the only real ways, maybe with MyBatis for complex schemas that just weren’t going to map cleanly, but these days I figure anything with actually proper behavior that’s at least smart enough to avoid the N+1 selects problem is all good. Mostly it’s because I’m finding that directly and transparently mapping entities into domain objects just doesn’t work out well for me anyway. Unless it’s a DB app first and foremost, there’s always some annoying facet of the ORM that’s going to get in your way and force you to compromise the design just to satisfy the ORM. Despite all the efforts to paper it over, the “impedance mismatch” is still there and probably always will be.

Offtopic: By the way, try H2 Database. It has better perfomance than SQLite.