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 clause
both 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 with
other frameworks.
Good to know that you found OpenJPA useful.
Will you please elaborate which aspects/features of OpenJPA are
distinct
from 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.
