Incidentally, if you’re working with DataView, you should probably also take advantage of Query’s pagination feature (Query#limit(int).offset(int)). This will add additional efficiency to the display algorithm. Eventually, this sort of functionality will be handled for you in the wicket integration project, but for the moment you’ll have to do it yourself.

Is there any way to omit (all) column names with Query.select? I tried Query.select(“*”) but didn’t work.

I think it is necesary to disable lazy-loading when using combined with Wicket/DataView because numerous selects (col*row times) occurrs with lazy-loading.

Batch creating is a more interesting thing to look at, since some databases support an “INSERT INTO blah (id,value) VALUES (?,?),(?,?)” syntax; allowing the insertion of multiple rows in a single statement. The problem is, this isn’t supported by very many databases (it’s not part of the ANSI standard), so you wouldn’t see a performance gain across the board.

This looks great. I am going to use AO as my ORM; hopefully, you will have a stable release by the time I’ll need to have a stable release myself.

On to the blog post topic: pre-loading is great. My app needs it in spades to trade some start-up time for better performance later.

However, what about batch saves? My app almost always gets new objects in batches of 10-1000. We also profiled behavior of our users, and they tend to batch their work and submit 50-100 items at a time, even though they can get each item processed immediately.

The dynamic proxy fires a PropertyChangeListener for every changed value. The problem is PropertyChangeEvent requires an old value as well. I’ll make that code conditional on the value already being cached, to avoid extra database hits. Thanks for finding this!

In the case of the relations, they’re always lazily loaded, since I haven’t been able to figure out a way to cache them without opening the door to a stale cache and thus inaccurate values. So, in short, no @OneToMany or @ManyToMany relation is eagerly loadable right now. Incidentally, if you have any ideas on the caching I welcome them.

… and this is what I can see. Why so many particular select hits?
14.8.2007 13:39:38 net.java.ao.DatabaseProvider executeInsertReturningKeys
INFO: INSERT INTO person (id) VALUES (DEFAULT)
14.8.2007 13:39:38 net.java.ao.EntityProxy invokeGetter
INFO: SELECT username FROM person WHERE id = ?
14.8.2007 13:39:38 net.java.ao.EntityProxy invokeGetter
INFO: SELECT firstname FROM person WHERE id = ?
14.8.2007 13:39:38 net.java.ao.EntityProxy invokeGetter
INFO: SELECT lastname FROM person WHERE id = ?
14.8.2007 13:39:38 net.java.ao.EntityProxy save
INFO: UPDATE person SET username = ?,firstname = ?,lastname = ? WHERE id = ?

public interface Person extends Entity {
public String getName();
public void setName(String name);

public int getAge();
public void setAge(int age);

@OneToMany
public Cars[] getCars();
}