Re: Inherited Relationships using Different Destinations
Re: Inherited Relationships using Different Destinations
- Subject: Re: Inherited Relationships using Different Destinations
- From: David Avendasora <email@hidden>
- Date: Fri, 5 Sep 2008 13:39:58 -0400
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 (and in the generated code)
is that any LotCode assinged to an Intermediate must be a
ManufacturedBatch.
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.
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).
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.
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.
Dave
_______________________________________________
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