Looking for a lightweight persistance framwork

[Lew]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown [sic]
persistance [sic] framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

You basically only have three choices:
1) Use some sort of custom serialization and re-invent the DBMS to handle your
tables and their relationships.
2) Use a DBMS like Derby (comes with Java already) or Postgres and write JDBC
calls.
3) Use a JPA framework like Hibernate, OpenJPA or EclipseLink with a DBMS like
Derby (comes with Java already) or Postgres.

I'd avoid 1) - there's no point in re-inventing the wheel when there are
thoroughly debugged, stable and robust alternatives.

I've done both 2) and 3), a lot. I've found that 2) seems easier at first,
but quickly runs into issues that 3) solves, forcing you to re-invent the
persistence wheel anyway.

Option 3) is a lot less "full blown" than you think. It involves a couple of
days learning and the addition of a couple of JARs to your project. It might
not be any more effort than 2).

People use the term "full blown" as a pre-judgment of possible solutions as if
it were synonymous with "harder and slower". Surprisingly, "full blown" often
comes with "easier and faster", as well as "more free of bugs", at least in
elementary uses of the so-called "full-blown" solutions.

 

[Lew]

Here's a list, at least. I can't recommend one above another. If you
do choose one from this list, post your impressions to this group, I
think some folks would be interested.

<http://java-source.net/open-source/persistence>

I've used Torque. It sucked.

I've used Castor, a little. It's a bit clunky, but serviceable. I don't like
it as much as other alternatives.

I've studied JDO and used it slightly. Go with JPA.

I've used OpenJPA and Hibernate quite a bit. Both are strong products that
aren't too difficult to use at all. (I am still not good at getting
automagical injection of entities and entity managers, though. It hasn't been
much of a handicap; I just instantiate explicitly based on the
persistence.xml.) The list omits EclipseLink (erst TopLink) for some reason;
it's another JPA layer that is very reliable.

Use a JPA framework. It's easier than raw JDBC calls, more effective and far
easier than other ORM frameworks I've used, performs well and is quite reliable.

 

[Roger]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown
persistance framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

Regards

 

[Giovanni Azua]

Hi there,

3) Use a JPA framework like Hibernate, OpenJPA or EclipseLink with a DBMS
like Derby (comes with Java already) or Postgres.

If I may add anything I would split point 3 into:

3.1) Stay at pure JPA i.e. define your ORM and configuration using the JPA
specs either annotations or xml (I prefer xml)
3.2) Use the native implementations to define your ORM e.g. Hibernate,
TopLink

If I may recommend I would go for 3.1 and stay away from 3.2 which might be
tempting with tools like TopLink Workbench. Now, while using the JPA API
switching to framework-specific interfaces is some times desiderable for
exploting richer functionality e.g. Criteria API. btw seens that JPA 2 will
support Criteria API so they are catching up
http://jcp.org/en/jsr/detail?id=317

People use the term "full blown" as a pre-judgment of possible solutions
as if it were synonymous with "harder and slower". Surprisingly, "full
blown" often comes with "easier and faster", as well as "more free of
bugs", at least in elementary uses of the so-called "full-blown"
solutions.

Very nice, I agree totally

Best regards,
Giovanni

 

[Giovanni Azua]

http://activeobjects.dev.java.net/

A bit misleading for a name ... Active Objects is a well known concurrency
pattern:
http://en.wikipedia.org/wiki/Active_Object

Best regards,
Giovanni

 

[Arne Vajhøj]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown
persistance framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

What do you really mean by that the project doesn't warrant something
like Hibernate?

You don't pay for it. If you would use it for a more complex project
then you must already know it. Code wise it is minimal effort.

Arne

 

[Karl Uppiano]

[...]

People use the term "full blown" as a pre-judgment of possible solutions
as if it were synonymous with "harder and slower". Surprisingly, "full
blown" often comes with "easier and faster", as well as "more free of
bugs", at least in elementary uses of the so-called "full-blown"
solutions.

In addition to which, they are generally more extensible, which is nice when
you discover after a few revisions, that your application really does need a
full blown solution.

 

[Giovanni Azua]

Hi Steve,

But perfect as a simple persistence framework.

I don't mean to be skeptical but to me this looks like another reincarnation
of JPA misleading it with a name of a concurrency Pattern to confuse the
masses. It is almost identical to JPA (like a copy-paste) but with the added
"These releases are for testing purposes only and should be considered to be
unstable":
https://activeobjects.dev.java.net/example.html

I would recommend going JPA, you go JPA you never go back

I use AO. It rocks.

How does it rock better compared to using JPA?

The "Why ActiveObjects?" looks to me like another rewording of the
"Hibernate is too full blown" vs my nicer lightweight argument, btw it
compares against Hibernate only, there is no a single word on JPA or any
other persistence provider:
https://activeobjects.dev.java.net/why.html

To my ears this type of slogans sound more like a threat than anything
appealing:

- My product A is better because it is more "Lite" "Lightweight"
- My product A can do in 1 line what product B does in 200 lines
- My product A is better because it is a jar only 5k big

I don't mean to proof anyone wrong or anything but looking at this solution
I wonder how can this be better for you than JPA.

Best regards,
Giovanni

 

[Arved Sandstrom]

Hi Steve,


I don't mean to be skeptical but to me this looks like another reincarnation
of JPA misleading it with a name of a concurrency Pattern to confuse the
masses. It is almost identical to JPA (like a copy-paste) but with the added
"These releases are for testing purposes only and should be considered to be
unstable":
https://activeobjects.dev.java.net/example.html

I would recommend going JPA, you go JPA you never go back

[ SNIP ]

Apart from the fact that it looks similar to JPA (granted, I just looked
at the example), I'm leery of anything like this that overly sells the
ability to quickly and painlessly change your data model. I'm not a
refactoring nut, but I do see some uses for it - one of them is _not_
constantly changing your database classes. Doing that, IMHO, is a sign
of bigger problems, and it's no selling point if your persistence
framework makes a bad habit easier.

AHS

 

[Lew]

Ease of setup is really my main concern, followed by volume of code needed to
do what you need to do. With AO, reading from your database, or persisting
your object to said database, only requires a couple lines of code.

Believe me, I'm not saying AO is for everyone. But I really like it.

The same considerations apply to JPA, in the simple case. You set up a 12-15
line XML file to define the database connection parameters, add 3-5 lines of
annotation to each entity POJO and 2 to instantiate an entity manager, and
Bob's your uncle. You don't even have to inherit an entity type.

Easy and compact and standard. And the Javadocs don't have spelling errors
(that I could find at first glance, unlike with AO).

 

[charlesbos73]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown
persistance framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

If the solution to your problem is really better expressed
using a relational DB *and* if you really need to use Java
then you have to deal with the "Object-Relational impedance
mismatch". In that case you'd be better to reuse one of
the tested and proven ORM out there, as others pointed out.

However, seen that it is a small web project and seen that
you happen to be posting in a newsgroup that talks about a
language that can be used in a OO way, it may be a good
opportunity to discover how simple and elegant an OODB can
be.

Note that this shall come as heresy in a newsgroup where
procedural advice on one hand, and RDB advice on the other,
are given daily as it was perfectly normal.

Some people like the XML + ORM flagellation coupled with
Java used in a purely procedural way (coupled with a
little GOTO-style programming here and there... But nothing
can go wrong when you know fineprint 6.3.2.17b of the JLS
right !?

Other consider this kind of development to be everything
that is wrong with Java.

Ted Neward calls this kind of development the "Vietnam
war of software development". Englightening read.

So what would people recommend?

Reading Ted Newards's "Vietnam of sofware development"

IBM DeveloperWorks "The busy Java developer's guide to db4o"
articles by the same author.

db4o

Model your solution using OO techniques (once again, this
is probably heresy in this newsgroup) and use an OODB like
db4o.

A small web project is probably the perfect place
to start and the beauty of OO is that if it is done
correctly, changes becomes trivial later on.

I'm probably very lucky to work in a domain where OO
shines... Most developers here are so used to do
ORM plumbing in their dayjob that their mind became
hardwired to answer "use a SQL RDB".

Mindboggling.

 

[Lew]

Some people like the XML + ORM flagellation coupled with

Merely calling it "flagellation" doesn't make it bad in reality.

Java used in a purely procedural way (coupled with a
little GOTO-style programming here and there... But nothing
can go wrong when you know fineprint 6.3.2.17b of the JLS
right !?

"Obscuring is distinct from shadowing (§6.3.1) and hiding (§8.3, §8.4.8.2,
§8.5, §9.3, §9.5). The naming conventions of §6.8 help reduce obscuring"?

There is no subsection 17 of JLS 6.3.2, and the JLS doesn't identify
paragraphs by letter.

Model your solution using OO techniques (once again, this
is probably heresy in this newsgroup)

Considering that Java is an O-O language, it's more than a little peculiar to
think that O-O modeling would be "heresy" in comp.lang.java.programmer.

and use an OODB like db4o.

Or use JPA (the Java Persistence API), which provides a superb impedance match
between the object and relational models.

I'm probably very lucky to work in a domain where OO
shines... Most developers here are so used to do
ORM plumbing in their dayjob that their mind became
hardwired to answer "use a SQL RDB".

Relational databases are good at modeling data, and have real strengths in
that regard. Their main strengths are flexibility when you want to support a
different object model off the same data, and the avoidance of data anomalies.
"Object-oriented" databases, really a rework of the old network-model
database systems, lock in a specific set of relations; relational databases do
not.

There are good reasons why relational databases have essentially taken over
the market from network-model databases, and why in over twenty-five years
so-called "object-oriented" databases have not gained much traction.

From a programming standpoint, JPA POJOs are about as simple as db4o objects
seem to be. As an added advantage, with JPA you don't usually have to
explicitly recognize that you're dealing with a database; you can focus on the
object model while working within the Java perspective. Not to say that you
can't use JPA in a data-model-aware fashion; people all too often do so, and
admittedly occasionally it's useful or necessary to do so. Nevertheless, JPA
is quite successful at keeping the Java perspective object-oriented without
sacrificing the distinct advantages of the relational model from the data
perspective.

JPA software plus relational database also allows one to configure different
object models atop the same back end.

Bottom line: for domain logic, object-oriented rules. For data storage,
relational rules. For that impedance mismatch, JPA rules.

 

[Mark Space]

I've used Torque. It sucked.

I've used Castor, a little. It's a bit clunky, but serviceable. I
don't like it as much as other alternatives.

I've studied JDO and used it slightly. Go with JPA.

Good reviews, that's for posting this!

 

[Tom Anderson]

If the solution to your problem is really better expressed using a
relational DB *and* if you really need to use Java then you have to deal
with the "Object-Relational impedance mismatch". In that case you'd be
better to reuse one of the tested and proven ORM out there, as others
pointed out.

However, seen that it is a small web project and seen that you happen to
be posting in a newsgroup that talks about a language that can be used
in a OO way, it may be a good opportunity to discover how simple and
elegant an OODB can be.

Note that this shall come as heresy in a newsgroup where procedural
advice on one hand, and RDB advice on the other, are given daily as it
was perfectly normal.

Some people like the XML + ORM flagellation coupled with Java used in a
purely procedural way (coupled with a little GOTO-style programming here
and there... But nothing can go wrong when you know fineprint 6.3.2.17b
of the JLS right !?

Other consider this kind of development to be everything that is wrong
with Java.

Others should probably calm down a bit. I'm aware that there's a been a
long, smouldering holy war around the subject of object DBs, but the fact
is that modern ORMs, working through JPA, are just as easy to use as
OODBs, if not more so.

Where ORMs win over OODBs is that because their data lives in an RDBMS,
it's accessible other than via the software layer - because the app i work
on ultimately stores its data in an Oracle database, i can dump it,
inspect it, modify with it, etc, with great ease. OODBs, on the other
hand, are black boxes - the only way to get at the data is through the
OODB, and sadly, there isn't the level of standardisation and tool support
around those as there is around RDBMSs.

I'm not saying that ORMs rule and OODBs drool, but that both are perfectly
workable. As would be, in this case, JAXB or plain old serialisation.

Ted Neward calls this kind of development the "Vietnam war of software
development". Englightening read.

You mean this, i take it:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

This seems to me to be an extremely long article which says nothing of
value: it throws out a lot of indisputable but irrelevant facts, suggests
a nonsensical allegory, and then draws an entirely unsupported conclusion.
In particular, it's striking that he spends a lot of time bashing ORMs for
things that OODBs are just as bad at - can an OODB handle his 'acceptable
spouse' query in less than O(n) time?

I'm probably very lucky to work in a domain where OO shines... Most
developers here are so used to do ORM plumbing in their dayjob that
their mind became hardwired to answer "use a SQL RDB".

Mindboggling.

The only thing that's really mindboggling here is your ranting prejudice
against ORM, and your contempt for other programmers.

tom

 

[Arved Sandstrom]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown
persistance framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

If the solution to your problem is really better expressed
using a relational DB *and* if you really need to use Java
then you have to deal with the "Object-Relational impedance
mismatch". In that case you'd be better to reuse one of
the tested and proven ORM out there, as others pointed out.
[ SNIP ]

Why don't we look at what that "object-relational impedance mismatch"
really means? Wikipedia has a pretty decent starter discussion:
http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch

1) Encapsulation - I don't really buy into the idea that there's a
problem here. I think of JPA entity classes as data objects. They are
unsophisticated classes that lack behaviour. Getters and setters are
pretty much the only API they need (apart from named queries, say, which
are still getters of a sort).

When you look at OODB code that works with data objects it looks very
similar to JPA code. Maybe the OODB has no entity classes, but so what?
Do you expect your data model to be changing frequently? If it is I
respectfully suggest that you've got bigger problems.

2) Data type differences - ultimately your data type in the OOP language
has to be stored as something concrete somewhere on the disk or in RAM.
Please don't tell me that in an OODB you don't have to think about this.
As for the reference issue, JPA handles that...I don't have to worry
about it.

3) Structural and integrity differences - _I_ haven't had serious
difficulties with anything that's talked about in this subsection. So I
can't comment on it.

4) Manipulative differences - hmmm, what do I want to do with data
objects? Get values, set values, retrieve lists of objects with given
criteria? Haven't had any problems doing this so far, with JPA. And the
code for doing so looks very similar to OODB code.

5) Transactional differences - the blurb here I don't really buy into.
Setting a primitive field on an object is just that, setting a primitive
field on an object. It's not a transaction to me unless I say it is.

In the final analysis, JPA is ably handling all these issues. Just like
an OODB is. Considering that the OODB code I've seen that manipulates
data objects looks very similar to JPA code, I'm left asking, what is
the advantage of an OODB to me?

As for representation and storage of data, well, the relational model
has worked very well for me so far. I haven't run across a situation yet
where it didn't work very well or fairly well.

I'm probably very lucky to work in a domain where OO
shines... Most developers here are so used to do
ORM plumbing in their dayjob that their mind became
hardwired to answer "use a SQL RDB".

Mindboggling.

I've used some of these OODBs. Right up to the point where I realized
that this emperor's new clothes didn't exist, and that I was gaining
precisely nothing over using an ORM with an RDBMS.

AHS

 

[Roedy Green]

I'm about to start a small web project that's going to need a small database
comprising about half a dozen master data tables and two or three
transactional tables. The size of the project doesn't warrant a full blown
persistance framework like iBatis or Hibernate, and I really can't be arsed
to roll my own. So what would people recommend?

for your options, see http://mindprod.com/jgloss/persistence.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"It wasn’t the Exxon Valdez captain’s driving that caused the Alaskan oil spill. It was yours."
~ Greenpeace advertisement New York Times 1990-02-25