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

[Jakob B. <jbr...@ho...>]

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

----- Original Message -----
From: "Kim Altintop" <ki...@de...>
To: "Jakob Braeuchi" <jbr...@ho...>;
<obj...@li...>
Sent: Friday, May 17, 2002 3:12 PM
Subject: Re: [OJB-developers] Problems with "non-decomposed m:n-mappings"/
extents - has it been fixed?


> 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
> >>
>
>