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