Re: Entity engine, "many" relations, foreign keys

[David E Jones]

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.


relation to
PartyContactMech. Why is it missing? We could have a field like
"partyContactMechFromDate", so it

mean we cannot easily
change the "fromDate" field in PartyContactMech (unless we do EECA).


point to a non-existent

such combination exists.

Advice? Or should we live without foreign key checks in such cases?

Jonathon

Jonathon -- Improov wrote:

In entity PartyContactMechPurpose, there is supposed to be a type "one" doesn't clash with "fromDate". Same for "thruDate". Of course, that would As it is now, it is possible to actually get PartyContactMechPurpose to PartyContactMech. Just mix up the partyId and contactMechId such that no

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

many-to-many usually requires a separate "match-make" table.


type "many" relations?

Do we have to insert an additional type "one" relation on field

"one" relation be created without specifying the full primary key?


query like "where attrName = whatever", so we can do a simple

PartyTypeAttr for example. Is that a many-to-many? Looks odd, though. A Is it correct to say that OFBiz does not do foreign key constraints with "attrName" in order to get the foreign key constraints checks? But can a Looks like the type "many" relation is merely a convenient means to do a

getRelated().

Jonathon

smime.p7s
Description: S/MIME cryptographic signature