mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

Can we keep the discussion on the mailing list? Thanks. I'll forward these
two messages there:

On Mon, Feb 7, 2011 at 10:55 PM, Scott Ritchie <s.ritchie73@xxxxxxxxx>wrote:

> Hi Matt,
>
> Ive been taking a look at mapping the ER diagram to java classes, as you
> suggested on friday, but I'm unsure of how to go about this, without further
> details on what this will be used for;
> Should it be a literal translation, or can it be coded in a more OO way?
> For example do classes need to be created for the associative entities like
> UserTeamRelation?  It seems fairly redundant in terms of Java code to avoid
> many-many relationships, but im unsure how GWT maps this to a database.
> Also for the unique ids used as primary keys, do these need to be coded for
> in the Java classes, or will the database handle that (ie do we have to
> generate the next sequential number in our code, or just ask the database
> for it?)
>
> Regards,
> Scott
>

On Mon, Feb 7, 2011 at 11:34 PM, David Coles <coles.david@xxxxxxxxx> wrote:

> If you want to get some idea of how ORMs work with Java, have a look at
> Hibernate docs. Unfortunately App Engine doesn't support Hibernate so it
> looks like we'll need to use
> http://code.google.com/appengine/docs/java/datastore/jdo/ or
> http://code.google.com/appengine/docs/java/datastore/jpa/.
>
> I'm not quite clear which is the better option, they both seem to be
> competing offical ORM standards with JPA being slightly newer but JDO
> being more mature.
>
> Also, one thing to watch out with the ER diagram is not to confuse
> primary keys with foreign keys (ones that reference a forign key in
> another class). At the moment both types seem to be represented by a *
> making things a bit confusing.
>
> David
>

OK, I didn't know GAE gives you two options for an ORM in Java. I've only
used the Python version of GAE, which has its own built-in ORM which you are
pretty much required to use.

For Scott and Prageeth -- An ORM (object relation mapper) is a mechanism for
automatically mapping classes onto database tables (and objects onto rows).
Whether it handles these weird "join tables" appropriately depends on the
ORM, I think.

Note that you asked "how GWT maps this to a database" -- note that GWT
doesn't define any database mechanisms. If you need a database on the
server, you bring your own. GWT server code is mostly normal Java code. *
However*, if we are to use Google App Engine (GAE), then that *does* define
database APIs and you are required to use those, you cannot bring your own.
That's what David is talking about above.

Looking at our ER diagram, there is only one such table in question, right?
The UserTeamRelation which is really just a way to get a * to *
relationship. The other two join tables (UserGameProfile and
UserAchievement) are *real* classes with data in them, so they need to be
given a full Java object.

I would say this is where there is some conflict between the "OO" way and
the "relation" way, and you should just let the relation way win. At least
in the Python version of GAE, it's one class per table, and if you need a
join table, you make a class for it.