Re: [OJB-developers] Problems with "non-decomposed m:n-mappings"/ extents - has it been fixed?

[Kim A. <ki...@de...>]

Hi again,

no it doesn't make sense really - I was only curing symptoms :(
However, I noticed that when PersistenceBrokerImpl::getMtoNQuery is called
while <items.class/> is refering to an interface, cld.getFullTableName()
returns null (which has some evidence) BUT when I call cld.getPkFields(),
the fields returned have a correct ClassDescriptor associated to them
(which is NOT cld but points to a ClassDescriptor of an implementor - don't
really know which one is chosen...). That's why I had the idea of
retrieving the table name via the pkField's ClassDescriptor as it never
returns null. Now you're right that if I had multiple primary keys defined
for that implementor, I would get duplicate table names.
 
I'm still not deep enough into OJB to tell how and when the ClassDescriptor
for my interface is assembled and so I can only think of the following
solutions for now:

 a) make cld.getFullTableName() return the table name of ANY implementor
    (and thus NEVER return null)
 b) introduce a member variable String[] implementorTableNames to 
    ClassDescriptor, which is only not-null if cld.isExtent() 
    returns true
 c) make a quick hack by changing cld.getFullTableName() into 
    cld.getPkFields()[0].getClassDescriptor().getFullTableName() in 
    PersistenceBrokerImpl::getMtoNQuery (-> that's roughly what I did 
    - ugly but worksforme ;-))

What do you think? Does THIS make sense?

Digging,
Kim
 

--On 5/17/2002 4:00 PM +0200 Jakob Braeuchi <jbr...@ho...> wrote:

> hi kim,
> 
> i cannot apply your patch, eclipse does not like it :(
> please send me the complete file.
> from what i can see sofar you get all pkFields from the class Descriptor
> and then from there you go back to the ClassDescriptor to get the
> table. i think you'll get the same table as many times as you have
> pkFields, does this make sense ?
> 
> jakob

[snip]