Re: Reference descriptor woes

[Jakob Braeuchi]

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]