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
Hi,
Why don’t you provide the Maven repository of the activeobjects?
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.
Hello,
‘users@activeobjects.dev.java.net’ is alive?
I sent a mail. but there is no response from anybody.
Thanks
Probably got caught in the list’s spam filter and never got submitted for approval. Did you subscribe to the list?
The only dependency I am unable to resolve via maven is snaq.db.ConnectionPoolManager.
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.
Post a Comment