• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Inherited Relationships using Different Destinations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Inherited Relationships using Different Destinations
      • From: Florijan Stamenkovic <email@hidden>
    • Re: Inherited Relationships using Different Destinations
      • From: David Avendasora <email@hidden>
References: 
 >Inherited Relationships using Different Destinations (From: David Avendasora <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: David Avendasora <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: Mike Schrag <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: David Avendasora <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: Mike Schrag <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: David Avendasora <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: Chuck Hill <email@hidden>)
 >Re: Inherited Relationships using Different Destinations (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: Inherited Relationships using Different Destinations
  • Next by Date: Re: Do DA's add a page to the app's cache ?
  • Previous by thread: Re: Inherited Relationships using Different Destinations
  • Next by thread: Re: Inherited Relationships using Different Destinations
  • Index(es):
    • Date
    • Thread