[OJB-developers] OJB relationships & more

[Christian S. <chr...@ne...>]

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?

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.

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"). It should load the full object data (vs. only the
foreign keys). For proxy classes, it should keep the raw data in a cache
attached to the relationship, and instantiate from that cache. Everything
else (especially singular loading) is unacceptable in a production
environment.

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?

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".


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