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: user@ofbiz.apache.org >>> 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: user@ofbiz.apache.org >>>> 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: user@ofbiz.apache.org >>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> > > > >
