Skip to content
Print

ActiveObjects 0.7 Released

22
Dec
2007

Just in time for the Christmas holidays, I give you ActiveObjects version 0.7!  This release sports a whole slew of minor performance tweaks and bugfixes, providing better reliability.  Also, we’ve greatly increased the number and scope of the unit tests running against the core.  This gives us more confidence that the code is indeed as stable as we hope.

Actually, the big ticket item for 0.7 is the introduction of polymorphic relations.  This feature is fully tested and stable, so I don’t anticipate it introducing any issues in the coming days as we narrow our focus to 1.0.  However, no feature is so well tested as to be certainly bug free under all circumstances.  I look forward to fixing any problems you may encounter with the library!

A few minor feature additions:

  • Support for persisting enum values
  • One-to-one relations
  • EntityManager#flush(…) now also flushes the relations cache

Looking toward the road ahead, things are really starting to settle down a bit.  The main feature I’m looking to implement for 0.8 is extensible value caching, which should allow you to determine how and where the cached field values are stored.  The main use-case behind this is support for memcached, which has been requested a few times and has actually been on the agenda since 0.3.  With memcached driving the value cache, ActiveObjects should be almost perfectly scalable.

To that end, it’s also worth mentioning that I did some profiling (using the NetBeans Profiler) using a Wicket-based web application I’m developing on the side.  I’m happy to report that the overhead imposed by ActiveObjects is extremely minimal.  In each test, the bottleneck was in the PreparedStatement#execute method (in JDBC).  Since ActiveObjects generates very streamlined and natural queries, it seems that this is really the minimal execution time possible for such database access.  Extrapolating further from this data, and given that the JDBC exec time was avg 40ms, while the execution time in the ActiveObjects API was on the order of 1ms-5ms, we can safely say that ActiveObjects is less than 10% slower than using JDBC directly (compare that to the 50% overhead claimed by ActiveRecord).  This “estimate” doesn’t even take into account the many performance advantages offered by ORMs over hand-coded database access (such as relations caching, optimal query construction, etc).

Anyway, enough shameless boasting.  As Hibernate has often pointed out, ORM benchmarks are usually worse than useless.  The only benchmark which really matters is how well the ORM performs in your application.  Try it out, see what you think.

Comments

  1. Hi,

    Why don’t you provide the Maven repository of the activeobjects?

    tarou Monday, January 14, 2008 at 2:13 am
  2. Mainly because I haven’t got the Maven build working yet. ActiveObjects has some build-time dependencies on a few libraries that aren’t in any maven repositories. It is on my list of things to do before 1.0, to figure out how to make the Maven build work properly and upload the stable release to a repository. Until then…

    I suggest you download a stable distribution of AO and configure it in your local repository if you wish to use AO through Maven. Unfortunately that’s about all that can be done at the moment.

    Daniel Spiewak Monday, January 14, 2008 at 2:44 am
  3. Hello,

    ‘users@activeobjects.dev.java.net’ is alive?
    I sent a mail. but there is no response from anybody.

    Thanks

    osamuo Wednesday, January 16, 2008 at 6:42 am
  4. Probably got caught in the list’s spam filter and never got submitted for approval. Did you subscribe to the list?

    Daniel Spiewak Wednesday, January 16, 2008 at 10:35 am
  5. The only dependency I am unable to resolve via maven is snaq.db.ConnectionPoolManager.

    Brian Sanders Saturday, February 9, 2008 at 3:24 pm
  6. Yes, one build-time dependency isn’t available. You’ll have to download the package yourself and import it into your local repository using the command maven provides.

    Daniel Spiewak Saturday, February 9, 2008 at 4:05 pm

Post a Comment

Comments are automatically formatted. Markup are either stripped or will cause large blocks of text to be eaten, depending on the phase of the moon. Code snippets should be wrapped in <pre>...</pre> tags. Indentation within pre tags will be preserved, and most instances of "<" and ">" will work without a problem.

Please note that first-time commenters are moderated, so don't panic if your comment doesn't appear immediately.

*
*