Re: [OJB-developers] OJB relationships & more

[Thomas M. <tho...@ho...>]

Hi Christian,

I was on a short vacation so my answer is a bit late...

Christian Sell wrote:
> 
> Hello,
> 
> a few questions:
> 
> Q1: ======================================
> Even though database connection configuration is done in the
> JdbcConnectionDescriptor element, configuring of JNDI lookup for datasources
> must be done in OJB.properties with the ConnectionFactoryClass property (and
> the JdbcConnectionDescriptor/url.dbalias element is then "misused" as the
> jndi lookup name). I find that rather confusing. Why not have a a
> "jndi-lookup" element inside the JdbcConnectionDescriptor instead?
> 

That's a good idea! The JNDI based Connectionfactory was a quick hack to
get someone started using OJB within a J2EE environment. Thus it will
need some polishing...
I will put your request on my todo-list.

> Q2: ======================================
> according to the docs, OJB supports "lazy loading" of relationships through
> the proxy class mechanism. This means, that when an objects are loaded, for
> each loaded object and every to-N attribute a separate query is issued to
> retreive the foreign key attributes for the referenced objects. Later, when
> the referenced objects are accessed, each referenced object is loaded
> individually with a primary-key-query (I call this "singular loading"). This
> leads to the following scenario:
> 
> say, we have classes A, B, C. Class A has 2 collection attributes which
> point to B and C, respectively. B and C both have dynamic proxyies
> configured. Loading all instances of A would lead to the following
> processing sequence:
> 
> 1) perform "select * from TABLE_A".
> 2) Iterate the result set. For each row:
>     2.1) instantiate the A object
>     2.2) perform "select b.foreign_key from TABLE_A a, TABLE_B b where
> b.foreign_key = a.primary_key"
>     2.3) Iterate the result set. For each row:
>         2.3.1) instantiate the proxy and add to collection a_bs
>     2.4) perform "select c.foreign_key from TABLE_A a, TABLE_C c where
> c.foreign_key = a.primary_key"
>     2.4) Iterate the result set. For each row:
>         2.4.1) instantiate the proxy and add to collection a_cs
> 
> then, for each access to an object referenced through the collections a_bs
> or a_cs, another SQL statement would be issued. Now say we have 2 instances
> of A in the database, which both hold 20 references in each collection
> attribute. I was to access all objects in the above described data set, over
> time the number of SQL statement issued would be
> 
> 1 + number_of_collection_attributes + (number_of_collection_attributes *
> number_of_referenced objects),
> i.e. 1 + 2 + 2 * 20 = 43.
> 
> This loading scheme is extremely inefficient, especially since the number of
> statements issued increases linearily with the number of objects referenced
> (and accessed) in the collections. A smart JDBC programmer (or O/R tool)
> could handle all with 1 (!) outer join statement, or at most 3 statements.
> If I am right, I dont think the proxy mechanism increases efficiency a lot,
> since it only saves the object instantiation, but incurs a possibly
> 1000-fold increase of DBMS accesses.
> 

Of course, if you iterate over all elements of the B- and C-collections
Proxies are inefficient. It would make no sense to use proxies here, as
you know in advance that all objects in the collection attributes have
bo accessed.
Proxies can improve performance if only "some" of the Bs and Cs have to
be accessed.

> I think a lazy relationship loading mechanism must be implemented such, that
> it performs the foreign-key join query only when the relationship itself is
> accessed ("resolved").

In my proxy design I don't diffentiate between 1:1 references and 1:n
references. I will think of your idea to have special proxies for 1:n
attributes. 

 It should load the full object data (vs. only the
> foreign keys). 

I see one possible disadvantage of your solution here: Say we have your
proxies. Object A will then be created with two proxy attributes for the
B- and C-collection.
Now we have to access only the fourth element of the B-Collection.
According to you proxy mechanism all 20 B-objects contained in B are
instanciated on this access to the collection.

You will end up with 19 superfluous full instanciations versus 19
superfluous instanciations of Proxy objects with my existing concept.

For proxy classes, it should keep the raw data in a cache
> attached to the relationship, and instantiate from that cache. 

Maybe a tough problem as OJB proxies must be serializable due to the
client/server architecture.

>Everything
> else (especially singular loading) is unacceptable in a production
> environment.
> 

I will have a look at TopLink to see what they are doing here.

> Did I miss something?
> 
> Q3: ==================================
> I am wondering about the field/class ids in the repository.xml file. Why
> assign separate ids when the names would do just as well?
> 

Class ID's are superfluous. Field ID's are necessary to provide a order
relation for the Comparator used for sorting.
There will be a complete review and cleanup of the existing DTD once we
have included all 1.0 features to the existing DTD (n:m relationships,
automatic foreignkey assignment, JNDI naming)

> Q4: ==================================
> Are there any plans to remove the need for separately mapping foreign key
> attributes? I find this a rather annoying requirement, which clearly defeats
> the notion of "transparence".
> 

I'm not sure if I understand you right? 
Currently OJB requires to set foreign key attributes manually.
(E.G: we create a new A with 20 B objects in a collection attribute.
a.primary_key is computed automatically with the <autoincrement>
features. But we have to set the b.foreign_key attributes referencing to
a.primary_key manually.)
This is of course annoying and has to be replaced by some automatic
solution. This feature is already on the todo list. But I have not
started working on it.

> Of course I am willing to lend a hand in any of these matters
> regards,
> Christian
> 

Thanks,

Any help is appreciated a lot!


Thomas

> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers