Looking for a lightweight persistance framwork

Discussion in 'Java' started by Lew, May 16, 2009.

  1. Lew

    Lew Guest

    Roger wrote:
    > 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
     
    Lew, May 16, 2009
    #1
    1. Advertising

  2. Lew

    Lew Guest

    Mark Space wrote:
    > 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.

    --
    Lew
     
    Lew, May 16, 2009
    #2
    1. Advertising

  3. Lew

    Roger Guest

    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
     
    Roger, May 16, 2009
    #3
  4. Hi there,

    "Lew" <> wrote in message
    > 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, May 16, 2009
    #4
  5. "Steve Sobol" <> wrote in message
    > On 2009-05-16, Roger <> wrote:
    >> 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?

    >
    > 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
     
    Giovanni Azua, May 16, 2009
    #5
  6. Lew

    Arne Vajhøj Guest

    Roger wrote:
    > 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
     
    Arne Vajhøj, May 17, 2009
    #6
  7. Lew

    Karl Uppiano Guest

    "Lew" <> wrote in message
    news:gumt09$nhh$...
    [...]
    > 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.
     
    Karl Uppiano, May 17, 2009
    #7
  8. Hi Steve,

    "Steve Sobol" <> wrote in message
    >>> http://activeobjects.dev.java.net/
    >>>

    >> A bit misleading for a name

    >
    > 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
     
    Giovanni Azua, May 17, 2009
    #8
  9. Giovanni Azua wrote:
    > Hi Steve,
    >
    > "Steve Sobol" <> wrote in message
    >>>> http://activeobjects.dev.java.net/
    >>>>
    >>> A bit misleading for a name

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

    [ 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
     
    Arved Sandstrom, May 17, 2009
    #9
  10. Lew

    Lew Guest

    Steve Sobol wrote:
    > 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).

    --
    Lew
     
    Lew, May 17, 2009
    #10
  11. Lew

    charlesbos73 Guest

    On May 16, 6:37 pm, Roger <> wrote:
    > 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.
     
    charlesbos73, May 17, 2009
    #11
  12. Lew

    Lew Guest

    charlesbos73 wrote:
    > 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.

    --
    Lew
     
    Lew, May 17, 2009
    #12
  13. Lew

    Mark Space Guest

    Lew wrote:

    > 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!
     
    Mark Space, May 17, 2009
    #13
  14. Lew

    Tom Anderson Guest

    On Sun, 17 May 2009, charlesbos73 wrote:

    > On May 16, 6:37 pm, Roger <> wrote:
    >
    >> 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.


    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

    --
    Basically, at any given time, most people in the world are wasting time.
     
    Tom Anderson, May 18, 2009
    #14
  15. charlesbos73 wrote:
    > On May 16, 6:37 pm, Roger <> wrote:
    >> 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
     
    Arved Sandstrom, May 18, 2009
    #15
  16. Lew

    Roedy Green Guest

    On Sat, 16 May 2009 20:37:11 +0300, Roger
    <> wrote, quoted or indirectly quoted
    someone who said :

    >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
     
    Roedy Green, May 19, 2009
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chad Crowder

    Framwork Version issues

    Chad Crowder, Aug 11, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    357
    Natty Gur
    Aug 13, 2003
  2. Sergio Baca
    Replies:
    0
    Views:
    318
    Sergio Baca
    Nov 17, 2003
  3. Replies:
    0
    Views:
    306
  4. Francois Meehan

    Looking for a DB for object persistance...

    Francois Meehan, Feb 6, 2004, in forum: Python
    Replies:
    1
    Views:
    304
    Mike C. Fletcher
    Feb 6, 2004
  5. Replies:
    8
    Views:
    138
Loading...

Share This Page