AutoFetch available in Ebean 0.9.7
Status: Beta
Brought to you by:
ahahibrahim2
Menu
▾
▴
I have just release Ebean 0.9.7 which includes support for AutoFetch. It also includes a small eclipse project with a pre-populated H2 database so in theory you should be able to try it out fairly easily.
http://www.avaje.org/autofetch.html
I have put up a page (http://www.avaje.org/autofetch.html) describing AutoFetch on my website. Let me know if you want any changes to it.
Thanks, Rob.
Great news!
Congratulations! Thanks for the kudos on your page. At this point your EBean Autofetch implemention is probably than my implementation of Autofetch for Hibernate.
Regards,
Ali
Typo:
At this point your EBean Autofetch implemention is probably ** better ** than my implementation of Autofetch for Hibernate.
Well I had a big advantage in that I could modify the internals of Ebean to provide better support for AutoFetch.
Re the Kudos... well you deserve it. Perhaps I'm jumping the gun here, but I was thinking the other day that if you could get a MVCC Database vendor interested... then you'd probably get even more interesting things happening. For example, some object graphs will be used a lot at the top rather than evenly. This could be supported in a much more performant way (BIG TIME) and maintain Read Consistency if the MVCC Database exposed its internal time/counter. Obviously that sort of database cooperation is will be very hard to get and proprietary but it seems to me that AutoFetch could be leading us toward transparent ORM... if only there was a open source java MVCC grid database...
I don't understand your last comment very well... However, I would like to discuss it more as I am always looking for good research ideas and I would be willing to get my hands dirty with a real database that uses MVCC (like Postgres?) if necessary.
Regards,
Ali
Roughly what I've been thinking is that there are 2 reasonably large issues with ORM today. One is the inefficiencies we face in getting and converting 2 dimensional results into object graphs. The other is that many times we build a list of object graphs and yet the user really only uses the top x objects/rows. Typically a UI screen shows a page of data (say 20 objects) and the user looks at just the first page or two before doing something else... yet we have pulled back a great many more rows from the DB and converted them to objects graphs and hold them in memory on the app server (overhead that was unnecessary really).
Perhaps the first issue is like a square peg going into a round hole. At the moment we just use a big hammer - not too subtle :)
The second issue I'd describe as "Array Fetching". In the old client server days we'd keep a cursor open on the DB and scroll the cursor on demand as the user paged through their data (Oracle Forms and PowerBuilder did this stuff for you automatically) - this approach won't scale to the level we need. Some people would use limit offset (or similar) and execute multiple queries to perform a similar trick. The problem you encounter once you start executing multiple queries is that they are not read-consistent wrt each other. The 2nd, 3rd, 4th etc queries are affected by changes to the DB after the 1st query was started and so the actual results between a single query and multiple can be different. Aka, you can't transparently take a big query and break it up into smaller ones without introducing read-consistency issues (or using a single transaction at a higher isolation level).
The profiling information AutoFetch gathers can help with both these situations. It basically can tell the ORM which query strategy is best based on the object graph usage. Looking forward if an MVCC database exposes its timestamp/counter (perhaps something like Oracle flashback query) we could potentially break up a big query into smaller queries with a fetch-ahead type mechanism and it would all be completely transparent to the user (at least that's my theory).
The square peg round hole problem also could be solved in a similar'ish manor (maybe/potentially/I'm hoping) but we also might need to be a bit more cunning and radical.
The last point (java open source grid db) was basically that some of these things would work better with the cooperation of a DB vendor and that it would almost certainly require a MVCC database - thats a very big ask I'd say. Some of this may be possible with flashback queries right now but I haven't had the time to look at it.
Sorry, took at while to reply... maybe easier to email me in future :) rbygrave at yahoo dot com.
Cheers, Rob.