[OJB-developers] AW: a couple questions

[Mahler T. <tho...@it...>]

Hi Matthew,

> -----Urspr=FCngliche Nachricht-----
> Von: Matthew Baird [mailto:ma...@so...]
> Gesendet: Donnerstag, 14. Februar 2002 18:43
> An: 'Mahler Thomas'
> Betreff: a couple questions
>=20
>=20
> when you are loading an object that has a relationship to=20
> many objects (a
> one to many relationship), the sql that you generate to load,=20
> what does it
> look like?

You can enable tracing of SQL statements in the OJB.properties file by
setting ojb.broker.accesslayerSqlGenerator.LogLevel=3DDEBUG

>=20
> Let's say A has relations to many B's.
>=20
> In castor, the query that is generated includes all the A=20
> attributes, and
> the foreign key from B that refers to A. so
>=20
> SELECT A.id, A.foo, A.bar, B.fk_to_A FROM A, B WHERE ....
>=20
> what this results in is you get a resultset back with=20
> multiple repeated
> rows. How does objectbridge do it?
>=20
> Also....
>=20
> when I do a query in objectbridge and get many results, do I=20
> materialize
> those objects from an underlying resultset as I need them, or does
> objectbridge do all the object materialization up front? I=20
> looked at the
> code and it looked like the former, but I wanted to get confirmation.
>=20

Maybe my English is too bad. I don't exactly understand your question.

The process for loading an A with a Collection of Bs works like follows
(simplified version):
1. generate SQL for materialization of A (primitive Attributes only):
   "SELECT A.id, A.foo, A.bar FROM A WHERE ...."
2. retrieve all 1-1 references
3. retrieve all 1-n references
3a. if the B collection descriptor is marked as lazy no further
materialization happens but a CollectionProxy is placed in the B =
collection
attribute. This allows loading on demand.
3b. If the B collection descriptor is not lazy a getCollectionByQuery =
is
performed to retrieve the collection attribute.
3b1. This query looks like "SELECT B.id, B.foo, B.bar, B.fk_to_A FROM =
B, A
WHERE B.fk_to_A =3D A.id". OJB retrieve a ResultSet based on this =
query. OJB
use RsIterators to read all B instance into the collection attribute.
3b2. If the Class B is configured to use instance proxies the B objects =
are
not fully materialized from the current row. Only lightweight proxies =
are
generated.
3b.3. If no proxies are use Objects are read fully.

This concept allows for maximum laziness during the matreialization =
process.

But: OJB does currently not allow to perform just one large JOIN =
statement
to materialize large object nets from a single resultset. This would =
require
a major redesign.

I hope this answers some of your questions.

cu,

Thomas

> m
>=20