> 1) 'Assuming that the entities for each of the participating tables
> do not yet exist, follow these steps to easily create subentities
> from a parent entity:'
I love this part of the manual -- that they use the term "easily" and
then proceed to explain a really ridiculous confusing process fairly
vaguely. I reread this section 472 times when I was writing the
vertical inheritance wizard.
> Only mentioned ticking or unticking the parent entity as abstract
> depending on whether you'll be fetching those objects on their own
> or not.
>
> 2) 'Assuming that the entities for each of the participating tables
> already exist, do the following to implement vertical mapping in an
> EOModel:'
>
> Mentions flattening the class properties like so:
> "If you created the child entities by choosing Create Subclass from
> the Property menu, you now need to delete the attributes that are
> inherited from the parent entity. This is necessary to avoid
> redundancy since the attributes you just flattened reflect the same
> attributes as the inherited attributes do."
>
> But I'm not sure why they'd need to be flattened if the above
> example didn't require it... i.e., why not just accept the
> inherited members? I think they would only need to be flattened if
> the parent entity was abstract perhaps.
Because you're spanning tables, so you don't have those columns in
the partial subclass table -- they only exist in the superclass
table. So you have to flatten them into the subclass entity so EOF
knows where to get the values from. However, I agree that it could
be way smarter about this. But on the flip side, it's fairly
commonly recommended that you avoid vertical inheritance as it's the
worst performing (albeit cleanest design) of all of the inheritance
types.
ms
This archive was generated by hypermail 2.0.0 : Wed May 16 2007 - 02:50:27 EDT