Can someone point me to an example or some document? I find no reference here http://ofbiz.apache.org/docs/entity.html
Skip -----Original Message----- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 04, 2007 11:06 AM To: user@ofbiz.apache.org Subject: Re: Entity engine, "many" relations, foreign keys Hugh? Manually specified indexes? Those have been there for years... -David On Dec 4, 2007, at 12:01 PM, [EMAIL PROTECTED] wrote: > 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 >> >> > >
