On Aug 6, 2009, at 00:16 , Pinaki Poddar wrote:
Hi,
I have not come across vertical and horizontal analogy w.r.t. fetch
plan -
and it did provide a neat imagery. But this analogy still refers to
a 'boxy'
or tabular world view popularized (or monopolized) by RDBMS.
Yes I fully agree.
If one thinks 'out of the box', then
a) a query for objects select a list of 'root nodes' {R:r}
and b) the query fetches a graph rooted in each node r.
And c) fetch plans are a specification to define a sub-graph on
closure of
r.
This is exactly that !
For recursive parent-child relationship, for example, one can
specify a
Fetch Plan to traverse the child-to-parent a fixed number of times
-- a
notion neither supported in SQL nor in JPA based FETCH JOIN.
Jean-Baptiste BRIAUD -- Novlog wrote:
Any comments on that vision ?
On Aug 5, 2009, at 16:33 , 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 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.
-----
Pinaki
--
View this message in context:
http://n2.nabble.com/Custom-proxy-%3A-idea-review-needed-tp3376839p3395110.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
