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

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

Hi Jakob,

unless I didn't check out the wrong branch (ojb-1-0) your fix IS included
in .400. However, it didn't work out for me but - hooray! - I tracked it
down: ojb.broker.singlevm.PersistenceBrokerImpl::getMtoNQuery is not
accumulating table/field information correctly (i.e.,
cld.getFullTableName() always returns null here).

I made a small workaround which seems to do the job for me. Attached is the
patch - maybe you could check this and tell me if I'm right (I didn't run
the test suite against this yet). I could supply a small test case that
illustrates the issue if needed.

Regards,
Kim


--On 5/17/2002 7:57 AM +0200 Jakob Braeuchi <jbr...@ho...> wrote:

> hi kim,
> 
> i made a quick fix for m:n with extents on May 3. and a fix for m:n path
> expressions on May 8 but i think they are not in .400.
> 
> jakob
> 
> ----- Original Message -----
> From: "Kim Altintop" <ki...@de...>
> To: <obj...@li...>
> Sent: Thursday, May 16, 2002 3:02 PM
> Subject: [OJB-developers] Problems with "non-decomposed m:n-mappings"/
> extents - has it been fixed?
> 
> 
>> Hi all,
>> 
>> while porting my app over to work with OJB I ran into the following
> problem:
>> if I got a CollectionDescriptor like this one
>> 
>>  <CollectionDescriptor id="2">
>>    <cdfield.name>foos</cdfield.name>
>>    <items.class>MyFooInterface</items.class>
>>    <inverse_fk_descriptor_ids>666</inverse_fk_descriptor_ids>
>>    <indirection_table>aggregate2interface</indirection_table>
>>    <fks_pointing_to_this_class>aggregate_id</fks_pointing_to_this_class>
>>    <fks_pointing_to_items_class>foo_id</fks_pointing_to_items_class>
>>  </CollectionDescriptor>
>> 
>> where - as you can see - the items.class is pointing to an interface
> (could
>> as well be an abstract class), that is, a class is not itself mapped to a
>> table but solely consists of extent classes, OJB seems to have problems
>> finding the correct table(s) for the extent classes (yes it DOES realize
>> that is has to look for extents). I believe that the problem is similar
>> to the one described here:
>> 
>> http://sourceforge.net/mailarchive/message.php?msg_id=1502546
>> 
>> One reply to this post says that a "quick fix" has been submitted.
> However,
>> I couldn't get the .400 release to work ("[DEFAULT] ERROR:
> FIELDDESCRIPTOR:
>> Can't find member dMapId in ojb.odmg.collections.DMapEntry")...
>> 
>> I'm now wondering if I should a) wait for the next release, b) pull my
> hair
>> out on getting .400 to work or c) fiddle around with a CVS version
>> because the "quick fix" isn't applicable to my problem...?
>> 
>> Thanks in advance for any directions!
>> 
>> Kim
>> 
>> _______________________________________________________________
>> 
>> Have big pipes? SourceForge.net is looking for download mirrors. We
>> supply the hardware. You get the recognition. Email Us:
>> ban...@so... _______________________________________________
>> Objectbridge-developers mailing list
>> Obj...@li...
>> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>