Hi Jakob,
Can you drop me a hint as to what to search on. I did a search on 'identity'
and 'extent' but nothing relevant came up. I am really interested in this
problem because currently it makes it impossible for me to implement a
persistent class which has a link to any other persistent class.
Imagine that I have an ACL class. It has a reference to user and a reference
to a generic abstract persistent class. If I ensure (which I do) that my
primary keys are unique across all tables in the db, I can easily verify
permissions on any persistent class that I am working on. But if we travel
up the extent hierarchy every time I need to reference concrete class from
another concrete class then it means n db lookups where n is the number of
tables in my database.
Maybe there is some other method of implementing this kind of scenario in
OJB that is not obvious to me. (BTW I have been snooping around the OJB code
and I have to say -- very lucid! easy to understand and work with)
Cheers,
--Bill.
----- Original Message -----
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Sunday, March 09, 2003 1:40 AM
Subject: Re: Reference descriptor woes
> hi bill,
>
> there was a thread about the same issue in ojb-dev.
>
> this is what thomas posted:
>
> There was a reason for this design.
> Say there is an abstract class A and a concrete class B extending A.
> No say there is a B instance b with a primary key value '17'.
>
> If we do not use the toplevel extent to define Identies it could happen
> that OJB addresses this object as A{17} or as B{17}.
> this result would violate base rules like
> if x == y then id(x) == id(y)
>
> We detected this issue a long time ago An I thaugt there was a testcase
> covering it...
>
> hth
> jakob
>
> V.B. Skrypnyk wrote:
>
> >Sorry, please disregard the previous post, I overlooked that this code
isn't
> >called when the loading is lazy.
> >
> >BUT, I am still a bit confused: in PersistenceBrokerImpl.java in method
> >getReferencedObject() which is called from retrieveReference() there is a
> >line:
> >
> >// ensure that top-level extents are used for Identities
> >referencedClass =
descriptorRepository.getTopLevelClass(rds.getItemClass());
> >
> >I wonder why we need to go to the top of the extent hierarchy, since the
> >rds's class has been explicitely declared by the programmer. Because what
I
> >noticed was that since I have a top class called SojbEntity which is the
> >superclass for all persistent classes in my app, it was the one looked
for
> >when the reference needed to be retrieved, so all tables where basically
> >scanned for the primary key equal to the value of the foreign key in the
> >class that had the reference.
> >
> >In other words, let's say we have the following hierarchy:
> >
> >SojbEntity
> >|- Customer
> >|- Contact
> >|- User
> >
> >Customer has a reference to its administrator which is of class User. If
I
> >ask for that reference to be retrieved, I don't want the PersistentEntity
to
> >be searched, only User. Otherwise, Customer, Contact and User will be
> >searched. Ideas?
> >
> >BTW, I replaced the line in the code above with code that just picks up
the
> >current ReferenceDescriptor class and it seemed to have eliminated the
extra
> >table lookups for me. Am I really breaking something here?
> >
> >Cheers,
> >--Bill.
> >
> >
> >----- Original Message -----
> >From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
> >To: "OJB Users List" <[EMAIL PROTECTED]>
> >Sent: Saturday, March 08, 2003 9:02 PM
> >Subject: Reference descriptor woes
> >
> >
> >
> >
> >>Hi,
> >>
> >>I am confused. Here is a snippet from the documentation:
> >>
> >>
> >>
> >>>>A proxy reference is based on the original proxy class concept. The
> >>>>
> >>>>
> >main
> >
> >
> >>difference is that the >>ReferenceDescriptor defines when to use a proxy
> >>class and not the ClassDescriptor.
> >>
> >>
> >>>>In the following mapping the class ProductGroup is not defined to be a
> >>>>
> >>>>
> >>proxy class in it's >>ClassDescriptor. Only for shown relationship a
proxy
> >>of ProductGroup should be used:
> >>
> >>Now this is the ObjectReferenceDescriptor.java snippet:
> >>
> >> public Class getItemProxyClass() throws PersistenceBrokerException
> >> {
> >> if (m_ProxyOfItems == null)
> >> {
> >> m_ProxyOfItems = getClassDescriptor().getRepository().
> >> getDescriptorFor(m_ClassOfItems).getProxyClass(); <<<
> >>
> >>
> >proxy
> >
> >
> >>comes from descriptor
> >> }
> >> return m_ProxyOfItems;
> >> }
> >>
> >>The code goes to the reference class's class descriptor and tries to get
> >>
> >>
> >the
> >
> >
> >>proxy class from there, and the only way it can happen is if the proxy
IS
> >>defined there. If this is correct, it means that the only way a
reference
> >>proxy would work is if the class-descriptor for the corresponding
> >>
> >>
> >reference
> >
> >
> >>class is defined, contrary to the documentation. It also discards a
fairly
> >>important optimization feature because now the user is confined to using
> >>proxies globally across any handling of the main class which will
probably
> >>take a substantial hit during the population of collections.
> >>
> >>Is there something I am missing in this picture?
> >>
> >>--Bill.
> >>
> >>
> >>---------------------------------------------------------------------
> >>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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
