Hi there,
On 08/03/2006, at 11:23 AM, Chuck Hill wrote:
On Mar 7, 2006, at 4:04 PM, Scott Winn wrote:
Certificate (average of 2 per File)
Ticket (about 12 per Certificate)
Item (about 30 per Ticket)
Part (usually 2 per Item)
The main hierarchy (above) consists of to-many relationships going
down and to-one relationships coming back up. The entities in the
hierarchy aren't the problem though because they are not the
objects being fetched. The issue I am having is mainly with
entities outside the hierarchy that are related to entities in
it. There are several relationships like this:
Certificate -> Company : Company ->> Certificates
Ticket -> Shipper : Shipper ->> Tickets
Item -> Location : Location ->> Item
OK, these are what I expect are causing you the problem. That is,
the to-many part of these. A certificate needs to know its
company. But does a company really need to know all of its
certificates? Does it use them? Do you use company().certificates
() in code rather than fetching the certificates for a particular
company? Would it present a problem to use a fetch on certificates
where company = X rather than use company().certificates()?
Consider the answers to these. It may be that you can avoid
modeling the Company ->> Certificates relationships. The same
questions apply to Shipper ->> Tickets and Location ->> Item. If
you do need them, and they do make sense in the context of your
application, then you should go with Anjo's suggestion. In a
nutshell, avoid relationships from lookup objects to transactional
objects. I've seen such relationships modeled very often just
because they can be modeled and it makes sense at first look. But
they can cause performance problems when there are many objects in
the relationship.
Maybe it would makes sense to set both a restrictingQualifier and an
externalQuery for all toMany destination entities (seeing as whatever
qualifier you come up with for fetching from Items would most likely
be consistent with some default qualifier that you'd desire if simply
following the relationship to the entity. That way, for most times,
you can stop thinking about this stuff and just follow the
relationships as intended...
e.g., it's often unlikely that you'll be dealing with historical data
on a regular basis (or even whilst importing data) so why not filter
them out by default on the entity. So maybe something like the
following could make sense:
public class Application extends WOApplication {
public static final EOQualifier NON_HISTORICAL_QUALIFIER;
static {
String format;
NSMutableArray values;
format = "%@ > %@ AND %@ = %@ etc";
values = new NSArray(new Object[] {
"created", <some timestamp>,
"blah", <somevalue>,
etc
});
NON_HISTORICAL_QUALIFIER = EOQualifier.qualifierWithQualifierFormat
(foramt, values);
}
public Application() {
super();
Enumeration mn;
...
// set restricting qualifiers for to-many entities
mn = EOModelGroup.defaultGroup().models().objectEnumerator();
while (en.hasMoreElements()) {
EOModel aModel;
Enumeration en;
aModel = (EOModel)en.nextElement();
en = aModel.entities().objectEnumerator();
while (en.hasMoreElements()) {
EOEntity anEntity;
Enumeration rn;
anEntity = (EOEntity)en.nextElement();
rn = new
NSArray(anEntity.relationships()).objectEnumerator();
while (rn.hasMoreElements()) {
EORelationship aRelationship;
aRelationship =
(EORelationship)rn.nextElement();
if (aRelationship.isToMany()) {
EOEntity destinationEntity;
destinationEntity =
aRelationship.destinationEntity();
if
(destinationEntity.restrictingQualifier() == null) {
destinationEntity.setRestrictingQualifier
(NON_HISTORICAL_QUALIFIER);
}
}
}
}
}
}
}
In either case, you might want an EC per import file that's discarded.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
