Not sure it's really related but maybe a better chance to advertise ;o) Done
Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > how about linking this with the entity one as a complete documentation. > https://issues.apache.org/jira/browse/OFBIZ-1387 > > Jacques Le Roux sent the following on 12/4/2007 10:21 PM: > > Or even better read and then add annotations/documentations that others > > will read and maybe complete/enhance... > > > > https://issues.apache.org/jira/browse/OFBIZ-1398 > > > > This part of the work, as for code, benefits to all but is more neglicted. > > Because most people just read the DTD as Jonathon > > suggested. Nevertheless having it as code-completion should motivates > > everyone. > > > > Jacques > > > > De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > >> Skip, > >> > >> Read the DTDs. See ${component:entity}/dtd/entitymodel.xsd . > >> > >> For an <entity>, there are <field>, <prim-key>, <relation>, <index>. > >> > >> Jonathon > >> > >> [EMAIL PROTECTED] wrote: > >>> Gads Adrian. I never knew of the existence of this tag. Thanks. It is > >>> perfect. Someone needs to document it in the entity engine guide or at > >>> least somewhere prominent. I just did a search for this tag and found > >>> dozens of uses, but somehow, I missed it even though I looked at > >>> OrderHeader's definition a gazillion times. > >>> > >>> Are there any other cool undocumented DB features? > >>> > >>> Skip > >>> > >>> -----Original Message----- > >>> From: Adrian Crum [mailto:[EMAIL PROTECTED] > >>> Sent: Tuesday, December 04, 2007 11:47 AM > >>> To: [email protected] > >>> Subject: Re: Entity engine, "many" relations, foreign keys > >>> > >>> > >>> Why won't the <index> element work? > >>> > >>> [EMAIL PROTECTED] wrote: > >>>> Ya BJ, seen that. What I want to do is create an index that is simply > >>> used > >>>> for speed lookups. I do this now in postgres after install has been > >>>> done. > >>>> It would just be nice to be able to specify it in the entitydef file. > >>> But, > >>>> it aint a big deal. Easily done manually in postgres. > >>>> > >>>> Skip > >>>> > >>>> -----Original Message----- > >>>> From: BJ Freeman [mailto:[EMAIL PROTECTED] > >>>> Sent: Tuesday, December 04, 2007 11:09 AM > >>>> To: [email protected] > >>>> Subject: Re: Entity engine, "many" relations, foreign keys > >>>> > >>>> > >>>> have you looked at this for tools > >>>> https://localhost:8443/webtools/control/view/checkdb > >>>> > >>>> [EMAIL PROTECTED] sent the following on 12/4/2007 11:01 AM: > >>>> > >>>>> It would be nice to have the foreign key checks as well as ways to > >>>> creating > >>>> > >>>>> indexes on non-key fields. There is a great performance increase having > >>>> an > >>>> > >>>>> index in some tables. Now I have to do in manually inside of the DB > >>>>> which > >>>>> is fine. > >>>>> > >>>>> Skip > >>>>> > >>>>> -----Original Message----- > >>>>> From: Jonathon -- Improov [mailto:[EMAIL PROTECTED] > >>>>> Sent: Tuesday, December 04, 2007 3:08 AM > >>>>> To: [email protected] > >>>>> Subject: Re: Entity engine, "many" relations, foreign keys > >>>>> > >>>>> > >>>>> Ah, wait. Note one more thing. > >>>>> > >>>>> In entity PartyContactMechPurpose, there is supposed to be a type "one" > >>>>> relation to > >>>>> PartyContactMech. Why is it missing? We could have a field like > >>>>> "partyContactMechFromDate", so it > >>>>> doesn't clash with "fromDate". Same for "thruDate". Of course, that > >>>>> would > >>>>> mean we cannot easily > >>>>> change the "fromDate" field in PartyContactMech (unless we do EECA). > >>>>> > >>>>> As it is now, it is possible to actually get PartyContactMechPurpose to > >>>>> point to a non-existent > >>>>> PartyContactMech. Just mix up the partyId and contactMechId such that no > >>>>> such combination exists. > >>>>> > >>>>> Advice? Or should we live without foreign key checks in such cases? > >>>>> > >>>>> Jonathon > >>>>> > >>>>> Jonathon -- Improov wrote: > >>>>> > >>>>>> I found this from David Jones: > >>>>>>> Foreign keys are done for type "one" relationships, not type many. A > >>>>>> type > >>>>>>> "many" relationship is usually just the reverse direction of a type > >>>>>> "one" > >>>>>>> relationship so the FK covers both. > >>>>>>> > >>>>>>> What would it mean to have a foreign key on a type "many" > >>>>> relationship?" > >>>>> > >>>>>> Then a corresponding "one" relation will supply the foreign key > >>>>> constraint? > >>>>> > >>>>>> What about a many-to-many relation? Look at entity PartyAttribute and > >>>>>> PartyTypeAttr for example. Is that a many-to-many? Looks odd, though. A > >>>>>> many-to-many usually requires a separate "match-make" table. > >>>>>> > >>>>>> Is it correct to say that OFBiz does not do foreign key constraints > >>>>>> with > >>>>>> type "many" relations? > >>>>>> > >>>>>> Do we have to insert an additional type "one" relation on field > >>>>>> "attrName" in order to get the foreign key constraints checks? But can > >>>>>> a > >>>>>> "one" relation be created without specifying the full primary key? > >>>>>> > >>>>>> Looks like the type "many" relation is merely a convenient means to do > >>>>>> a > >>>>>> query like "where attrName = whatever", so we can do a simple > >>>>> getRelated(). > >>>>> > >>>>>> Jonathon > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > > > >
