Well, I've got it working, somewhat. I'm creating a new instance of
the other subclass, copy all the attributes and relationships over,
then delete the old instance.
The problem I'm having is that I'm somehow getting two instances of
the target subclass. Maybe someone can look at this code and tell me
what I'm doing wrong.
public void setNutritionValueType(NutritionValueType aValue) {
if (nutritionValueType() == null || aValue == null) {
super.setNutritionValueType(aValue);
} else if (aValue != nutritionValueType()) {
CalculatedNutritionValue nv = new CalculatedNutritionValue();
editingContext().insertObject(nv);
nv.setIsSuspect(isSuspect());
nv.addObjectToBothSidesOfRelationshipWithKey(nutritionBlock(),
"nutritionBlock");
nv.addObjectToBothSidesOfRelationshipWithKey(nutritionElement(),
"nutritionElement");
nv.addObjectToBothSidesOfRelationshipWithKey(aValue,
"nutritionValueType");
nv.setSortOrder(sortOrder());
nv.addObjectToBothSidesOfRelationshipWithKey(unitOfMeasure(),
"unitOfMeasure");
nv.setValueQuantity(valueQuantity());
editingContext().deleteObject(this);
}
}
It seems very simple. I just don't get where I'm getting a second
instance. If I save the EditingContext, I do get two new records in
the DB.
Any guesses? Anyone?
Dave
On Feb 13, 2008, at 3:01 PM, Ken Anderson wrote:
David,
I've been down this path many times, and my current recommendation
is to just have some kind of type on the object that identifies it
as one or the other. I have a situation where I store the class
name of a 'calculator' class in the EO, and then dynamically call
static methods on that class to do the heavy lifting.
Ken
On Feb 13, 2008, at 11:15 AM, Mike Schrag wrote:
I could just create a new object of the new class and delete the
existing one
yes
What is the best way to get WO to pickup the subclass change
immediately?
Or is this just a bad way of doing things?
yes
Inheritance hierarchy is to be treated like a PK -- It's an
unchanging attribute of an EO. In fact, it's actually part of the
EOGlobalID.
What you're describing is very similar to the Employee vs Manager
modeling problem. The general consensus is that when an Employee
becomes a Manager, it's not changing types, it's changing Roles,
so it's actually a Person=>Role, where Role is Manager or Employee
and you are just changing the relationship, not the intrinsic type.
You should consider type to be immutable for your own safety and
the safety of those around you. The correct way is to delete your
old class and make a new one, or maintain a relationship to
(something like) a NutrionValueCalculator that changes (if there
is a lot of other state in this object other than just this value).
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kenlists%
40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%
40avendasora.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
