Thanks much. I didn't realize ODMG "offered such a non-relational
constructs" :)
David
|---------+--------------------------->
| | Thomas Mahler |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED] |
| | |
| | |
| | 04/01/2003 01:46|
| | PM |
| | Please respond |
| | to "OJB Users |
| | List" |
| | |
|---------+--------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: OJB Users List <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: Re: ODMG Persistent Collections: (was Re: OJB vs Hibernate)
|
|
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Hi again David,
If we have a look at 1:n associations we normally have the following
database tables.
There is a master table holding entries on the "1" side and a Detail
table holding the entries of the "n" side.
The Master object has a Collection attribute that holds Detail elements.
In normal use the "n" side is dependend on the "1" side. That is without
a Master object there is no Detail Collection.
Second important constraint: all Collection entries must be of the same
type (incl. subclasses)
With ODMG persistent Collections it's a bit different.
you could do the following in ODMG:
Implementation odmg = ...;
Database db = ...;
Transaction tx = odmg.newTransaction();
tx.begin();
DList list = odmg.newDList();
list.add(new MyCar());
list.add(new MyHouse());
list.add(new MyBoat());
list.add(new MyHorse());
db.bind(list, "all my belongings");
tx.commit();
tx = odmg.newTransaction();
tx.begin();
Dlist belongings = (DList) db.lookup("all my belongings");
tx.commit();
As you can see
1. DList collections are first class persistent objects. They can be
stored without any "Master" Objects.
2. They may hold arbitrary elements.
3. ODMG has a persistent naming mechanism that allows to store arbitrary
object a root elemets of persistent object graphs.
These features are specified by ODMG and so we have to implement them to
be compliant.
To implement 1.) We need the OJB_DLIST table.
To implement 2.) we need the OJB_DLIST_ENTRY table. It holds "pointers"
(actually serialized Identities) to the persistent elements of the
collection. The elements themselves are stored in their respective user
tables.
To implement 3. We have the OJB_NRM table.
The platform.html document covers all OJB internal tables.
cheers,
Thomas
[EMAIL PROTECTED] wrote:
> Can you elaborate on this (or point me at written doc) What exactly is
> stored in the database tables?
>
> If a have a House, and it contains a persistent collection of Rooms,
since
> each Room contains an oid referring back to the House it belongs to, what
> else is there? I've seen the various DLIST tables, and often wonderd
about
> them.
>
> Thanks
> David
>
>
>
>
>>I'm not really sure I like all the tables
>>you have to create to run the ODMG part.
>
>
> It's not a question of choice for us. If you want to be ODMG compliant
> you have to provide persistent collections. To provide persistent
> collection you must be able to store them in the DB. Hence all those
> tables.
>
> If you don't want to use ODMG persistent collection you don't need those
> tables!
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
