Re: Of Inheritance and AwakeFromInsertion
Re: Of Inheritance and AwakeFromInsertion
- Subject: Re: Of Inheritance and AwakeFromInsertion
- From: Chuck Hill <email@hidden>
- Date: Wed, 19 Mar 2008 09:41:08 -0700
On Mar 19, 2008, at 8:42 AM, David Avendasora wrote:
On Mar 19, 2008, at 11:02 AM, Chuck Hill wrote:
On Mar 19, 2008, at 5:21 AM, David Avendasora wrote:
Hi all,
I've run into something that _seems_ to work, but just seems
"wrong" and I don't see how to do it "right".
I have the following inheritance structure in my model:
LotCode (NOT abstract)
ManufacturedBatch extends LotCode.
When I call awakeFromInsertion on the superclass I do it as
follows :
public void awakeFromInsertion(EOEditingContext ec) {
super.awakeFromInsertion(ec);
if (lotCodeType() == null) {
setLotCodeType(1);
}
}
But when I call awakeFromInsertion on the subclass I have to do
this:
public void awakeFromInsertion(EOEditingContext ec) {
super.awakeFromInsertion(ec);
if (lotCodeType() == null || lotCodeType.equals(1)) {
setLotCodeType(2);
}
}
I know that you should _never_ change the class of an EO after
creating it, but that's exactly what I'm doing here.
Well, no. You are changing the value that EOF uses to determine
class when it fetches the object.
So, even though the restricting qualifier value is changing that
doesn't actually impact what attributes and relationships that EOF
sees as part of the Object?
No.
Is it just when it goes to save the EO that it checks to see it's
type to know how to save it?
No.
What parts of EOF pay attention to the restricting qualifier?
Fetching. See, its like this. When you create a class:
ManufacturedBatch newManufacturedBatch = new ManufacturedBatch();
EOF knows the class and can use that to determine the entity (unless
you have the same class implementing multiple entities which is why
you should not create EOs like this, but I digress). That gets
encoded into the EOGlobalID:
protected EOKeyGlobalID(String entityName, int hashCode)
Now, when EOF fetches data from the database, I has no idea what class
to use. So it uses the table name and the restricting qualifier to
discern which class to instantiate and which entity it is for. A
global ID is created as above.
Now, as long as that global ID is around, if EOF refetches the data,
it will use the global ID to determine the class and entity. BUT once
all of the snapshots are released and the global ID goes away, when
EOF next fetches it, it uses the table name and the restricting
qualifier. So if you create a ManufacturedBatch with a type code of
1, EOF will treat it as a ManufacturedBatch object _until_ all
references to it are gone. Then when it fetches the data again, it
will hand you a LotCode. That is when things get fun in your
application, as you fetched on ManufacturedBatch, but got instances of
LotCode. Avoid that. :-)
When awakeFromInsertion is called on the subclass, the first thing
it does is call super.awakeFromInsertion, which sets the class to
LotCode, but then I change it to a ManufacturedBatch immediately
after.
The Java object is already created. It class does not and can not
change.
Since the restricting qualifier != instanceOf, I have to be careful
because it would be possible to instantiate as one thing but set the
qualifier to something else.
Yes, it is. See above. Been there. Done that.
If I don't do this, a call of ManufacturedBatch
newManufacturedBatch = new ManufacturedBatch() returns a LotCode
instead.
! (newManufacturedBatch instanceof ManufacturedBatch)? That seems
highly improbable just after a call to new.
Okay, I was confusing myself. In the UI of the application it shows
(based on the restricting qualifier's value) if the object is a
LotCode or ManufacturedBatch. I was interpreting this as ==
instanceOf. It was actually an instance of ManufacturedBatch, even
though the UI showed LotCode.
Better to base the UI on the entityName. Probably clearer too.
So, is this an exception to the rule "never change an EO's class"
or is it because I'm doing it in the awakeFromInsertion process
that it is okay?
Or is it wrong to do this and I just haven't been bitten by it yet?
Either your description above is inaccurate, or something is
totally wacked out in your code.
Most likely a little of column A, and a little of column B.
:-)
Chuck
--
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