Re: Expanding Import
Re: Expanding Import
- Subject: Re: Expanding Import
- From: Chuck Hill <email@hidden>
- Date: Tue, 7 Mar 2006 16:23:39 -0800
On Mar 7, 2006, at 4:04 PM, Scott Winn wrote:
On Mar 7, 2006, at 3:00 PM, Chuck Hill wrote:
On Mar 7, 2006, at 2:46 PM, Scott Winn wrote:
Thanks for the response Chuck.
The solution, is to not include this relationship in your model
or to not make it a class property. In most cases like this,
you really don't need this relationship or seldom need it. In
this case you can mimic it by fetching the related objects when
needed.
So what I need to be doing is
1) Remove the offending relationships from the entity's Class
properties
Or remove them entirely if you don't need them for delete rules.
2) Make my foreign key fields (in the formerly related entity)
Class Properties
3) Use primaryKeyForObject to set the relationship in the foreign
key by hand (as it were)
Um, no. If you don't have the relationship, there is no need to
set it. I may misunderstand your model. What I understand is
that you have two, reciprocal relationships, Certificate ->>
Stations and Station ->> Certificates. If you don't need the
Station ->> Certificates relationship (but do need the Certificate
->> Stations one), you can just eliminate it. What are you
describing is a symptom of updating a very large to-many
relationship. If you don't need the relationship, removing it
will dramatically speed things up.
I guess I misunderstood you. I thought you were talking about
removing the EOModeler defined relationship and setting database
relationship by hand. I do need the data to be related somehow.
I would have to be pretty desperate to set database relationships by
hand. I think I would have to go wash my hands after doing that.
Your description has left me rather confused as to details of what
you are doing and it is hard for me to see what, if anything, can
be eliminated. Perhaps you can try to describe the relationships
and process again. It may also be that Anjo's solution is the
answer to your problem.
Let me try to give you (and all the other nice people reading this
post) a better picture of what I am doing. Maybe it is
horrifically bad database design, but I can always blame the legacy
system, right? :-)
Or blame me being thick. :-)
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.
By far the worst one is Item -> Location : Location ->> Item. As I
am reading through the file, I hit a locationCode that may or may
not have a matching DB entry. I need to look it up and create a new
one if it doesn't exist. Then I create the Location/Item
relationship to the Item I am currently reading in
Using addObjectToBothSidesOfRelationshipWithKey?
and in due course I save the EC.
When I do the Location fetch (after reading just a few files) I
seem to be pulling in thousands of Items through the relationship
that I don't want to change. The ec.updateObjects() call looks in
part like this. . .
{
values = {
locationName = <com.webobjects.foundation.NSKeyValueCoding$Null>;
locationCode = "99";
Company = "<NCCompany 18424f _EOIntegralKeyGlobalID[Company
(java.lang.Integer)1]>";
locationDescription = <com.webobjects.foundation.NSKeyValueCoding
$Null>;
Items = (
"<NCItem 7ee9eb _EOIntegralKeyGlobalID[NCItem (java.lang.Integer)
538]>
< NCItem 2f7af3 _EOIntegralKeyGlobalID[NCItem (java.lang.Integer)
733]>
. . . A few thousand Items already stored . . .
< NCItem 6c5525 _EOIntegralKeyGlobalID[NCItem (java.lang.Integer)
308]>
. . . Then come the actual updates . . .
< NCItem 5f1fa0 <EOTemporaryGlobalID: 0 0 -64 -88 42 -3 0 0 -54
-4 80 8 0 0 1 9 -62 108 -102 -115 -97 90 -24 -73>>
. . . not nearly as many . . .
< NCItem 2462d5 <EOTemporaryGlobalID: 0 0 -64 -88 42 -3 0 0 -54
-4 67 15 0 0 1 9 -62 108 -102 -115 -97 90 -24 -73>>");
};
this = "<NCLocation 97048e _EOIntegralKeyGlobalID[NCLocation
(java.lang.Integer)1]>";
},
You are somewhat mis-interpreting that. You are confusing the
contents of an object that will be updated with the objects that will
be updated. What you have there shows a single NCLocation object that
will be updated. The NCItems are just properties of that object and
will not be updated unless they also appear directly in the
updatedObjects() list. It might be clearer to log out
ec.updatedObjects().valueForKey("entityName")
ec.insertedObjects().valueForKey("entityName")
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden