Pre-0.7 (the soon-to-be-released version in the SVN) enum storage wasn’t possible using the vanilla distribution. The extensible type system of course allowed for such a mapping to be trivially implemented (and that is how it is now done in the core), but previously it was not available “out of the box”.

After much wrestling with the pros and cons, the decision was made to use the ordinal value of the enum, rather than the String name. This obviously makes it slightly less readable on the database, but it allows for trivial name-refactorings without breaking database integrity. Thus, the corresponding type for enum is INTEGER.

Perhaps down the road AO will support database-specific type implementations like MySQL’s ENUM, but at the moment this too must be done outside of the core (possible, but not implemented).

AO actually doesn’t have it’s own query syntax. It’s just using PreparedStatement fragments. For the example you gave, the fragment of “query text” is actually concatenated directly into an SQL query, like so: “SELECT id FROM person WHERE ${query_text}”, and then executed with the specified parameters. I didn’t look, does BK actually use PreparedStatements? And if so, how effectively? This is a really important issue, especially for databases like Derby or Oracle which rely heavily on PS and have lousy performance without them.

Point taken on the SELECT * vs lazy load. Actually, it’s possible in AO to do this sort of thing (I added the functionality like two weeks ago, so like most things it isn’t documented yet). The code would look something like this:

manager.find(Person.class, Query.select(“*”).where(“name LIKE ? OR age > ?”, “Joe”, 9));

Query is just a preparedstatement builder class which allows things like: Query.select().where(“name = ?”, “Bill”).limit(5).order(“name”) => “SELECT id FROM ${table_name} WHERE name = ? ORDER BY name LIMIT 5″. The idea behind it is that it mimics the ActiveRecord find() syntax a bit, through the filter that Java doesn’t have symbols like Ruby.

*** Still requires a lot of boiler-plate code (it’s POJO based)

I may be misunderstanding something here. In BeanKeeper your class definition would be:

public class Person {
private String firstName;
public String getFirstName() { return firstName; }
public void setFirstName(String firstName) { this.firstName = firstName; }
}

In ActiveObjects your class (interface) definition would be:

public interface Person extends Entity {
public String getFirstName();
public void setFirstName(String firstName);
}

So, by “boilerplate code”, are you referring to the implementation of the getters and setters? I suppose it is a bit of extra code, but at the same time, being able to use POJOs like this gains you a lot of flexibility:

- You can easily add custom code to your getters and setters
- Works well to persist existing/legacy classes
- External users of your entity classes do not have know or care about the persistence manager, they just create and use POJOs like any other object

I suppose the above may just be general benefits of doing things the POJO way. Anyway, for my particular project, the above points were quite important – I’m sure there are cases where they are not as important (e.g. starting a new project from scratch).

*** Has it’s own query syntax (HQL is a big reason I avoid Hibernate)

Doesn’t AO have its own query syntax too? BeanKeeper queries don’t seem all that different from AO queries to me, for example:

manager.find(Person.class, “name LIKE ? OR age > ?”, “Joe”, 9); // AO
store.find(“find person where name LIKE ‘Joe’ OR age > 9″); // BK

*** Seems to be List based for relations, rather than the more intuitive (and performant) array based

BeanKeeper’s lazy lists are actually the primary reason I used the library for a previous project – you can execute queries that return huge lists with very low memory usage. By using the List interface instead of arrays, BeanKeeper can page objects into memory only when they are actually accessed. This sort of feature is really useful for reporting, where you may be dealing with queries that return hundreds of thousands of objects.

BTW, what is the reason that arrays are more intuitive? Doesn’t everyone these days use Collections instead of arrays (unless you’re doing some low-level stuff)? Regarding performance, it seems unlikely that there would be any noticeable difference between using arrays and Lists for an ORM library.

*** In ActiveObjects, every value is lazy-loaded and cached. So you use a minimal amount of memory for each entity.

Agreed, this is a benefit of using an interface and not a POJO. On the other hand, if you do need to access all the data in an object, it is more efficient to do a single SELECT * than to execute many smaller queries. The memory use of a single object does not typically cause too many problems – it’s normally only when you have thousands of objects in memory at the same time, and the BeanKeeper lazy lists address this issue quite well.

I’m definitely looking forward to trying out ActiveObjects soon. I have a few small BeanKeeper test programs, so it’ll be interesting to re-implement them with ActiveObjects and compare the code and results.

No, I wasn’t familiar with it actually. It does seem interesting though. My three problems with it just from reading bits of the tutorial:

* Still requires a lot of boiler-plate code (it’s POJO based)
* Has it’s own query syntax (HQL is a big reason I avoid Hibernate)
* Seems to be List based for relations, rather than the more intuitive (and performant) array based

The problem with POJO-based frameworks, beyond the added boiler-plate, is that everything must be eagerly loaded. Basically, you turn every entity retrieval call into a SELECT * Hibernate can get around this with bytecode manipulation, but personally I’m a little leery of letting random frameworks peer into my class internals.

In ActiveObjects, every value is lazy-loaded and cached. So you use a minimal amount of memory for each entity.

http://www.netmind.hu/persistence/

It’s another persistence library with a similar philosophy – zero configuration, no boilerplate code, no administration, etc. I’ve used it a bit in the past, and it’s really quite cool how it magically stores and loads objects without any ugly ORM code or configuration. If you are familiar with it, what would you say are main advantages of ActiveObjects over BeanKeeper?

Well, you’ve got two choices for the example you gave. You can define the database schema attributes to not allow nulls in the houseID field:

public interface Person extends Entity {
// …

@NotNull
public House getHouse();
@NotNull
public void setHouse(House house);
}

Or for a more complex rule, you could use AO implementations, which are definitely weird, but quite powerful. I’ll make sure I cover them in a future post.

@Eelco

I’ll take a look at those wicket sources. Since I’m working on a project using Wicket and ActiveObjects, it’d obviously be nice to make the integration as tight as possible.

I’ll have to look at cglib and similar. I briefly considered byte-code manipulation when designing the framework, but that always required weird hacks like custom classloaders etc… While I don’t have a problem writing framework internals which do weird stuff, I don’t want the API to be too bizarre.

Drop me a line if you want write access to wicket-stuff.