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