Re: Expanding Import
Re: Expanding Import
- Subject: Re: Expanding Import
- From: Scott Winn <email@hidden>
- Date: Tue, 7 Mar 2006 17:16:52 -0800
On Mar 7, 2006, at 4:23 PM, Chuck Hill wrote:
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.
Definitely not the WebObjects way I grant you.
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. :-)
What you, thick? All of us wannabes bow to your WOKnowHow.
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.
I think you have probably hit the nail on the head. It is very easy
to model relationships without thinking of the consequences. My
particular problem is that the rest of the app isn't built. I'm
doing the data end first so I'll actually have some data to test when
building the interface, reports, etc. So for the moment it is hard
to say what I will and won't need. I'll have a specific Company
object in the user's session, that is a given. The rest is a bit of
a question mark.
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?
Yup. That's what all the newbie examples say to do.
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")
I might not have been too clear in my comments, but I do understand
that the Items in the list are properties not individual objects to
be updated. But that kind of takes me back to my original
question . . . Is attempting to store this object (and a few others
like it) with all of its to-many relationship properties what is
bogging down the app? Is it an obvious, no brainer, yes, or should
WO be able to handle a few million properties like this? Seems a bit
ridiculous to be asking, but hey, what do I know?
It appears I need to streamline my relationships first, then when I'm
building the bulk of the app try to figure out what relationships I
can't live without. It was easy to create the relationships in the
first place; it should be just as easy to put them back. Then I'll
have to try and figure out how to pull off what Anjo was talking about.
Thanks much to everyone for the help. Let me know if anyone hears a
good rule of thumb for what does and does not need a relationship.
Scott
_______________________________________________
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