skip the webtools link I gave you showed indexes, not sure why you did not pick up on it. also if you have looked a any of then entities you would see them also.
[EMAIL PROTECTED] sent the following on 12/4/2007 12:57 PM: > 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 >>>> >>>> >>> >>> >>> >>> >> > > > > >
