Hi Jean-Baptiste,Thanks for your comments regarding the utility of the fetch plan in OpenJPA. The concept of a fetch plan with fetch groups is more than three years old but is still not widely adopted nor standardized in JPA.
Your description of "horizontal" versus "vertical" filtering is an interesting one. I hadn't heard of fetch plans described using this terminology before.
Thanks, Craig On Aug 5, 2009, at 7:33 AM, Jean-Baptiste BRIAUD -- Novlog wrote:
The need is simple : get trees of partially valuated business object instances from the "big graph" of possible linked business classes. The fact came from old SQooL (a bad IT joke from old school and old SQL) :1. only get back from DB what you need.2. the other thing is to try to make as few trip to the DB as possible. One request is better than several.DB will optimized if the request look like complex. In other words, let the DB optimize for you, as much as possible.So, I'm in Java, I want instances of my business classes but with only attributes I need (rule 1). That attributes that had to be taken or left from the DB can be @Basic one or any other relational one like @ManyToOne, @OneToOne, ...I also want to express that in one request ideally (point 2).I let the Java framework optimize for me and send as few SQL request as possible.Basically, there is 2 "filters" to distinguish :* vertical one that can filter several "lines" from the million in the table : this is the WHERE clause * horizontal one that can bring back only certain column : this is the SELECT clauseboth are usefull.Vertical one are well taken into account by all the frameworks I had to use.Horizontal one had been poorly taken into account by other frameworks I had to use. I can get back with some instances (vertical filter) but with all attributes (bad horizontal filter). Or I can have both working but the result is an array of hash tables and I need instances of my business classes. This is really bad since that hash map's keys are not the attribute (field) name but the position in the SELECT clause !Meta information is just lost in translation and nobody care :-)Some framework are able to handle poorly (better than not handling at all) horizontal filtering via eager or lazy loading but this only concern relational attributes excluding @Basic one and also, most of the time this can't be set dynamicaly and you have to provide as a developper specific constructor of your business class. All that horizontal filtaring has to be set statically via annotation or more painfully via XML but not dynamically. At the end, it is a lot of work for the developper for not having real horizontal filter.As a conclusion, and as far as I know, OpenJPA was the only one able to give me back some (efficient vertical filter) instances of my business classes partially valuated depending on my needs (efficient horizontal filter) both filters can be specified entirely dynamically if I want but it is also statically via annotation.This had been possible with only one request.Without any reference to an old OO DB, OpenJPA is a precious gemstone !On Aug 5, 2009, at 15:36 , Pinaki Poddar wrote:Hi,I can tell OpenJPA rocks, what I did had been tested impossible to do withother frameworks.Good to know that you found OpenJPA useful.Will you please elaborate which aspects/features of OpenJPA are distinctfrom other frameworks in your view? ----- Pinaki -- View this message in context: http://n2.nabble.com/Custom-proxy-%3A-idea-review-needed-tp3376839p3391748.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
