Object-Relational Mapping questions

[panos]

Hi,
I am an experienced Java programmer who has been doing his own
object-relational
mapping directly in JDBC, in a variety of financial applications. I
have always believed
that this was something a programmer (read, "me") should not have to
waste his/her
time doing. Finally, I have the opportunity to start a fresh project
with some leeway
to choose an Object-Relational Mapper. I have a few questions for any
one with
experience using these.

1. I definitely want to choose something that will be forward looking
-- that is, it is either the standard now, or will be soon. From what
I can gather, Hibernate seems to have the bulk of the users currently,
but JDO (JPOX?) or EJB 3.0 is grabbing the spot light. Can somebody
shed some light on this choice?

2. Are there any Auditing strategies that one can use in these mappers?
My systems always allow one to view all previous states of persisted
objects, as well as "turning back the clock" on all the objects in the
system, that is, showing the world as it was last week. Is this
possible?

3. One thing I haven't really seen in the documentation for these
products is how one updates existing schemas? E.g., if I have an
object with fields int x and String s and there are persisted instances
of this class, and then I add a third field Date d, what is the
mechanism to port the database to the new schema?

 

[carlo]

hi.

have you looked at mr. persister?

it is slightly more low-level than the other alternatives you mention
here, but through "scoping" it has a very nice connection and
transaction managements. The ORM mapping is transparrent if you are
using beans so integration with existing software is rather easy.

cheers,

 

[Adam Maass]

1. I definitely want to choose something that will be forward looking
-- that is, it is either the standard now, or will be soon. From what
I can gather, Hibernate seems to have the bulk of the users currently,
but JDO (JPOX?) or EJB 3.0 is grabbing the spot light. Can somebody
shed some light on this choice?

IMHO, Hibernate seems to be the safest choice by far right now. EJB 3.0 will
require a Bean Container (though, in theory, its persistence can be taken
out of the container.) JDO solutions are all-but-dead these days.

2. Are there any Auditing strategies that one can use in these mappers?
My systems always allow one to view all previous states of persisted
objects, as well as "turning back the clock" on all the objects in the
system, that is, showing the world as it was last week. Is this
possible?

You can plug various things into Hibernate's framework; you might find
something useful there. Or you might just implement auditing as something
your POJOs do as a matter of course. I'm sorry I can't be of more help
here....

3. One thing I haven't really seen in the documentation for these
products is how one updates existing schemas? E.g., if I have an
object with fields int x and String s and there are persisted instances
of this class, and then I add a third field Date d, what is the
mechanism to port the database to the new schema?

How do you go about updating existing schemas now? In general:

Write a migration script that get executed as part of a software upgrade;
Bundle new software that knows how to make use of the revised schema.

There is nothing magical about using an ORM tool that makes schema
migrations any different than what you have to deal with now.

-- Adam Maass

 

[panos]

JDO solutions are all-but-dead these days.

Why is it dead? Are people not using it? No support? How about JPOX?

How do you go about updating existing schemas now? In general:

Write a migration script that get executed as part of a software upgrade;
Bundle new software that knows how to make use of the revised schema.

There is nothing magical about using an ORM tool that makes schema
migrations any different than what you have to deal with now.

I was under the assumption that the ORM generates the database table
scripts.
Is that only for the initial creation of the table, and then you need
to write your
own table migration scripts?

 

[Adam Maass]

Why is it dead? Are people not using it? No support? How about JPOX?

Most of the industry buzz is around Hibernate. JDO solutions are generally
commercial, and the spec has been slow to develop. In the meantime, vendors
have implemented their own features in their products. And the featureset
has generally lagged behind... Hibernate.

Hibernate was free to ignore the spec committee and get stuff out the door
that people actually use.

I was under the assumption that the ORM generates the database table
scripts.
Is that only for the initial creation of the table, and then you need
to write your
own table migration scripts?

Some ORM tools will generate table creation scripts for you based on some
rules and what you have mapped. But no tool that I am aware of /requires/
you to use their table creation script feature; you can write the schema by
hand if you wish, or use any other database tool you wish to develop the
schema. The ORM tool manages the relationship between the database and your
objects; in an ideal world, your objects and the schema can evolve
more-or-less independently, as determined by experts in the relevant
domains. In fact, I'd be highly suspicious of table creation scripts
generated by an ORM tool; the schema might not be completely efficient. It
almost certainly will lack appropriate indexes, for example.

If you insist on using the ORM tool to generate the table creation scripts,
then by all means make use of tools that generate schema migration scripts.
They exist (at least for popular databases).