Hi there,
On 01/06/2007, at 10:50 PM, Craig L Russell wrote:
> On Jun 1, 2007, at 2:42 AM, Andrus Adamchik wrote:
>
>> On May 31, 2007, at 9:51 AM, Lachlan Deck wrote:
>>
>>> There are numerous uses for these partial instances (if you'd
>>> like to call them that) when you want to only fetch the
>>> characteristics of the parent, for example, without also having
>>> to fault in the data for the subclasses. e.g., if I have a
>>> service thread that once every 10 minutes or so polls a message-
>>> queue to send a message to a list of recipients the only data I'm
>>> interested in fetching in is that of the parent entity.
>
> I still have trouble with this. If this is a requirement, I'd
> suggest mapping the superclass independently, that is using a
> completely different class.
The question in the end is whether the tool/framework enforces what
in the end (as it seems to me) comes down to an object design
decision of which there are always various forks in the road as it
can depend on the needs of the individual application (which we all
know in reality can change/grow at any particular point in time
throughout the life of an application). e.g., such design decisions
cannot always be imposed upon legacy systems.
I'm simply suggesting that Cayenne (and any other ORM for that
matter) can quite simply allow for either case. To do so is at the
end-user's risk.
> Then you can have part of your application that doesn't care about
> the subclass part at all.
That certainly is a risk that is worth documenting for an end-
developer but I don't believe should be enforced by the framework. In
most situations (that I can envisage anyway) the use-case for
instantiating a parent entity (rather than the sub-entity to which it
belongs) would be in a read-only mode. But again that's application
specific.
> It would still be a very bad choice if you were to mix the model
> containing the full inheritance relationship and the partial
> mapping, because you would potentially have conflicting updates of
> the same data.
I'm not sure how that would be different from current update
conflicts. Perhaps that would depend upon the locking behaviour
(optimistic etc).
> But you would be avoiding the complexity and the usability issues
> associated with having an instance that was mapped as a subclass
> yet in memory had no subclass behavior.
Are there any particular complexities you have in mind?
For mine, any such complexity would be introduced by an individual
developer, I believe, in edge-cases where for some strange reason the
developer decides to modify the parent record (e.g., incrementing
some dateOfLastAccess field).
I suppose I keep coming back to this question: 'why should the
framework impose an ideal restriction when there are in reality
business cases for doing otherwise?' i.e., If allowing the parent
record to be fetched on its own without needing to additionally fetch
the sub-type characteristics allows for certain performance benefits,
for example, or otherwise then for mine: +1. Some other developer may
have some other needs for which these flexibilities finds a home. All
in all my persuasion is that best-practices (for hazy areas like
this) are best aimed at documentatation/white-papers.
The only complexity I can envision (at this stage - perhaps Andrus
would have a better idea) is dealing with the global ids for two
objects in memory that for all intents and purpose are the same
object, each of which are in separate contexts but where one was
fetched as the superclass rather than the subclass it was originally
created as. But other than that the normal rules would apply - i.e.,
where the mapped entity that the parent object corresponds to is the
parent entity that just happens to also have a sub-entity. I'm not
certain at this stage how the object graph would track these. But it
doesn't seem to be something that's conceptually difficult.
>>> This is not breaking any inheritance rules even in Java as I see
>>> it. It is after all possible in Java itself to have a non-
>>> abstract superclass. Whether this leads to a broken mapping or
>>> otherwise I don't believe should be a restriction enforced by the
>>> tool... but certainly you might like to document the advantages/
>>> disadvantages of such an approach.
>>
>> Hmm... Thinking about it from different angles, I tend to agree
>> with Lachlan. A user can bend the rules with a shallow fetch on a
>> non-abstract superclass, as long as (s)he understands that this
>> (a) breaks uniquing and (b) deleting or inserting such records is
>> asking for trouble.
>>
>> Still IMO, this is not related to the delete rule discussion. An
>> implied CASCADE is the right thing.
>>
>> Andrus
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Fri Jun 01 2007 - 09:54:55 EDT