Hi Jakob,
I think I just found a simple solution. If I hide the top abstract class
from OJB all works well. It also doesn't compromise anything, since I never
reference the top level class anyway.
Cheers,
--Bill.
----- Original Message -----
From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Sunday, March 09, 2003 2:22 AM
Subject: Re: Reference descriptor woes
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
