What do Java game developers use for Database persistence?

[sproket]

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

[OttoMeier]

sounds like mybatis could be the right tool for you.

[ReBirth]

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.

Games published by our own members! Check 'em out!

[sproket]

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.

[SimonH]

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.

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

[sproket]

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.

[ReBirth]

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.

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

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.

[sproket]

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.

[ReBirth]

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

[sproingie]

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

Games published by our own members! Check 'em out!

[65K]

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.

[divxdede]

(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)

[sproket]

Play 2.0 uses Ebean for Java and Anorm for Scala.  They're both available separately.
There's also Siena, another AR type thing:
<snip>

Thanks that's interesting.

[ReBirth]

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

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

[sproket]

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.

[ReBirth]

You can post it on Shared Code section.

[cylab]

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

[sproket]

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.

[sproingie]

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.

[dector]

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

[princec]

I use straight JDBC. I then got on with my life and wrote some games

Cas

[Riven]

I use straight JDBC. I then got on with my life and wrote some games

I should totally unleash my minimalistic JDBC wrapper upon you!

It takes the cruft out of the CRUD.

[princec]

It barely takes any time at all to write something like that though with a few annotations here and there. I don't have enough database stuff to warrant even bothering with it though.

Cas

[Riven]

Sure, it's not hard, but I haven't seen any jdbc wrapper as convenient as mine, yet

I'll post it in a few days, when I removed the worst bits

[Ultroman]

I would really like to see that wrapper, Riven. I've been pondering creating one myself, but I've been busy in school.

We just finished a JSP/EJB 3.0 project. I love EJB, though it is rather complex, and impossible to host cheaply. Please post this wrapper, so I won't have to resort to put up a private EJB-server ^^

[Riven]

I currently only have tested bindings to a MySQL db. It should work on every database that supports simple INSERT,SELECT,UPDATE,DELETE queries, because that's pretty much what this wrapper does.

The wrapper is really 'hands off' and non-intrusive, so the database table-design is leading. No effort is made into even storing metadata like @nullable. You'll get a typical SQLException from the server instead if you try to write a null value where it's not allowed.

A typical Account & Deposit class 'backed' by tables would look like:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

public class Account extends DataObject {    public String username;    public String passhash;    public String passsalt;    public String emailaddress;    public int money;    public Account() { super(); }    public Account(int id) { super(id); } } public class Deposit extends DataObject {    public Account account;    public int amount;    public Deposit() { super(); }    public Deposit(int id) { super(id); } }

Usage:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

Account account = new Account(3421); // performs a SELECT Deposit deposit1 = new Deposit(); // no SELECT deposit1.account = account; deposit1.amount = 40; deposit1.insert(); System.out.println("deposit #1 ID="+deposit1.id()); Deposit deposit2 = new Deposit(); // no SELECT deposit2.account = account; deposit2.amount = 42; deposit2.insert(); // INSERT System.out.println("deposit #2 ID="+deposit2.id()); deposit2.amount += 3; deposit2.update(); // UPDATE deposit1.delete(); // DELETE

Say you want to query all Deposits of an Account:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

public class Account extends DataObject {    public String username;    public String passhash;    public String passsalt;    public String emailaddress;    public int money;    public Account() { super(); }    public Account(int id) { super(id); }    public List<Deposit> getDeposits() {       // this is so common, that I will probably move the actual query behind a utility method.       return QueryDataObject.selectAll(Deposit.class,          "SELECT * FROM deposit WHERE account = ?",          this /* varargs: every '?' in the query requires an additional argument */);    } }

Say you want to query the Account of a Deposit:

1   2   3   4   5   6   7   8   9   10   11

public class Deposit extends DataObject {    public Account account;    public int amount;    public Deposit() { super(); }    public Deposit(int id) { super(id); }    public Account selectAccount() {       return (this.account == null) ? null : this.account.select();    } }

This shows the following:

1   2   3

Deposit d = new Deposit(37); // SELECT * FROM deposit WHERE somePrimaryKey = 37 // d.account is an instance, but is NOT filled with data, just an identifier, hence: d.account.select(); // SELECT * FROM account WHERE somePrimaryKey = d.account.id()

The DataObject class allows you to override the default names for the tablename and primarykey column.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20

public class DataObject {    public int id;        //        public String getTableName() {       return this.getClass().getSimpleName().toLowerCase(); // "Account" -> "account"    }        public String getPrimaryKey() {       return this.getTableName() + "id"; // "Account" -> "accountid"    } } public class Account extends DataObject {    @Override    public String getPrimaryKey() {       return "accountnr";    } }

The names of the (other) fields/colums are not configurable. They are used as-is. Java enums are supported and map directly to MySQL's ENUM type.



This is really all there is to it. Well, there is more, like connection pools and preInsert / preUpdate / postDelete / postSelect callbacks, so you can implement poor man's java-side triggers.

It's really simple, so you're really doing queries select()s, update()s, delete()s on individual objects. For select()s we have the QueryDataObject class, with methods which return List<...>





Is this what you're looking for? I'll only make it public when somebody actually needs it.

[Ultroman]

Seems legit I like it! Very simple and easy to use. You really should publish it. I know I'd love to poke around the code a bit, to see how it all fits together. It might be just what I need.

[Roquen]

I wonder how well akka's data-store works...that could potentially kill two birds with one stone for massive entity systems.

[sproingie]

I love EJB, though it is rather complex, and impossible to host cheaply.

How's free grab you?  JavaEE 6 on OpenShift

[sproingie]

I wonder how well akka's data-store works...that could potentially kill two birds with one stone for massive entity systems.

Akka doesn't have anything like a database or other flavor of data store that I'm aware of.  Is there something specific you're referring to?