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