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
