Quick and Easy Object Persistence: pBeans + Groovy Beans

Discussions

News: Quick and Easy Object Persistence: pBeans + Groovy Beans

  1. Michael Ivey writes about a quick and dirty object persistence scheme. It combines pBeans, a simple open source Java persistence framework, and Groovy. The combination gets him close to the laziness that he craves.
    I started my programming life in Perl, and I am a lazy programmer. I get frustrated when I have to write duplicate code, or put information in more than one place. I'll search the web for days, try sample applications in 10 different frameworks, and write hundreds of lines of test code to find a solution that saves me half an hour. Now that's lazy.

    I've been looking at persistence layers and frameworks lately. I don't like having SQL in my objects, partially because it makes things more brittle, and partially because I don't like writing SQL anywhere. I just want to write classes and instantiate objects, manipulate them for a while, and then have them stick around. I don't really care about the database itself. (In fact, most of the time I don't need a database, that's just a simple way to store stuff.)

    Prevayler-style in-memory storage is kind of cool, but it also places restrictions on how you structure your client classes. I don't want restrictions, I don't want extra work, and I don't want duplicated code or information. How do I do it?

    pBeans is one way. It really is as simple as I was looking for. Make some Beans, tag them with implements Persistent, make a store, and then put objects in the store and take them out. No SQL (one exception; read on), no XML, no mapping files. Free as in speech. Currently works with MySQL, Postgres, and SQL Server, and should be fairly easy to get working on other databases.
    Read Quick and Easy Object Persistence: pBeans + Groovy Beans
  2. Interesting, especially after the complexity of using
    other frameworks.

    Is there a way to use it in embedded database without
    using a separate server?

    Any idea how it makes sure the same object is
    returned no matter in which object is referenced? That's
    a cool feature.
  3. Hmmm...

    My first impression from five minutes with the javadocs (and I'm willing to be wrong on this, so please point out my errors).

     - No transaction support (!)
     - Naive queries
     - Pretty much non-existant handling of object relations - you are left to pass around the basic Store and manage related collections yourself.
     - Enforces table-per-class mapping
     - Non-trivial mappings require mapping information to be stores in additional classes, with forced naming conventions that violate Sun guidelines.

    I stopped looking at this point. This all sounds great if you never need to do anything other than the example given in the article.
    Extending a framework class
    Implementing a complex interface
    Writing XML mapping files
    Writing mapping classes
    Generating a database schema at compile time
    Code generation
    One word: gross.
    Well, pbeans fails on at least one of these - you have to write mapping classes for all but the most trivial cases. Plus, you have to implement an interface - not a complex one, granted, but its still persistence concerns leaking into your object model.

    I've written noddy persistence frameworks myself (and even - god forbid - a connection pool!), but only ever as a toy or educational exercise - I wouldn't *dream* of adding yet another half-baked framework to a SourceForge already bursting at the seams. Far better to contribute to hibernate, or iBatis, or torque, or OJB, or Castor, or... you get the idea.

    What problem does this framework actually solve, that the countless other frameworks don't solve already, and better? And why not contribute to an existing one, rather than knock out something semi-capable like this? I don't want to sound like an ass, but frankly we need another new open source persistence tool like we need another flavour-of-the-month IOC framework.
  4. Stop the presses!!! Trivial persistence found to be trivially easy!

    I think that if in a most cases your persistence needs are that trivial you probably don't need persistence. So Hibernate or JDO needs you to configure them - that's no surprise really given the number of sophisticated things you can do with them. This article proves that if you can build a toy app as if it's a toy app. That's hardly surprising.
  5. While the author may be lazy, I don't think pBeans is -- if you want lazy loading you have to do it yourself.

    Try JDO -- while there is more up front setup with JDO than pBeans, the marginal effort of adding another persistent capable class is small.

    Tom