Re: Inherited Relationships using Different Destinations
Re: Inherited Relationships using Different Destinations
- Subject: Re: Inherited Relationships using Different Destinations
- From: Chuck Hill <email@hidden>
- Date: Fri, 5 Sep 2008 10:56:40 -0700
On Sep 5, 2008, at 10:39 AM, David Avendasora wrote:
On Sep 5, 2008, at 12:50 PM, Chuck Hill wrote:
Once again, I have _no_ idea what you are doing / trying to do.
Are you trying to change the model to restrict the to-many in the
sub-class to just some of the entities that lotCodes() on the
superclass would return?
A LotCode is the most basic form of a LotCode. Most Raw Parts will
have LotCodes and we track information about each lot code such as
when it was received, from what vendor, etc. A ManufacturedBatch is
a LotCode for an Intermediate. ManufacturedBatches have additional
information and functions compared to a simple LotCode. Things like
the ManufacturingLine they were made on, how much of what other
LotCodes went into making this ManufacturedBatch, etc. In the real-
world an Intermediate must have ManufacturedBatches associated with
it - NOT just a LotCode. But since an Intermediate is-a Part, it
must have the LotCode relationship, in reality this LotCode must be
a ManufacturedBatch.
So what I'm trying to enforce on the Model
I think you mean "force" not "enforce" :-P
(and in the generated code) is that any LotCode assinged to an
Intermediate must be a ManufacturedBatch.
What you need, and want, IMHO, is a different relationship. You can't
just willy nilly change things. Maybe don't model lotCode() on Part
and just have it as a Java method. Then model that relationship on
each sub-class to point to the right thing.
In fact, there is yet another layer of Parts & LotCodes for items we
make and then sell to customers. This additional ManufacturedBatch
subclass keeps track of additional information such as customer it
was sold to, purchase order, date shipped, etc.
Mmmm, chocolate cookies....
That seems like it might be dangerous.
So in this situation, NOT being specific about what exact subclass
of LotCode is acceptable for the exact subclass of Part is actually
much more dangerous (from a business perspective).
I am more worried about a "making EOF lose its mind" kind of
dangerous. The other way to do this is to use Design by Contract,
which does allow this sort of thing. But I digress.
Are you just trying to avoid casting?
To some extent, yes, but I'm also trying to avoid having invalid
relationships defined on an Entity that I then have to write a cover
method for to make them truly match the real-world requirements
correctly.
Because your model is wrong me thinks. It suggests things that are
not true.
Why not just add a method like
public NSArray<ManufacturedBatch> manufacturedBatches() {
return (NSArray<ManufacturedBatch>)lotCodes();
}
It's not so much the getting I'm worried about. It's the setting.
Without overriding what EOGenerator creates for relationships, I'll
end up code that allows me (and the next developer) to add a LotCode
to an Intermediate's lotCodes relationship. Sure, I could write a
cover method, but why? Why not just Generate the class right in the
first place?
(and forgive any abusement of generics, I don't much use them).
Oh, don't worry. I abuse them all the time while using them.
You know, I absolutely believe that. ;-)
Chuck
--
Chuck Hill Senior Consultant / VP Development
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