Thanks Jaime,
I'm glad to hear that the idea is sound, but I'll also heed your
advice and leave it alone for now. I'll let Mark figure out how best
to crack this nut ;-)
Cheers,
Bob
On Wed, Mar 4, 2009 at 5:58 PM, Jaime Metcher wrote:
> Bob,
>
> That sounds about right. Essentially you are pr
Bob,
That sounds about right. Essentially you are providing the same gateway/DAO
functionality that Transfer would normally provide, but you're having to do
it manually. You might consider giving your new class a similar API to
Transfer, but that would be a considered trade-off of API convenience
Jaime,
Ah, I understand. In my experiment I hadn't considered collections of
employees. I had just assumed that there was no such thing as an
employee object - only analyst, designer, etc, which I think remains
true when we're talking about individual objects, but yes, it falls
apart when you n
Bob,
Having no mapping for the Employee class means the ORM can't hand you a
collection of Employees. If you wanted such a beast, you'd need combine the
collections of all the subclasses. The common Employee.cfc superclass gives
you common instance logic, but not common collection logic.
Anothe
Those are good points Jaime.
As you pointed out, the reason that we used a composite key for the
table was to prevent the situation (#1) in which the same record could
be treated as both a Designer and an Analyst. I suppose one could
circumvent that by passing in the EmployeeType for an Analyst
If I recall correctly, the potential caching issues are all to do with
loading the same row as two different instances. There are three different
ways this can happen:
1. You load the same employee as both a Designer and an Analyst (these are
the sibling subclasses in Bob's example).
2. You load
Bob,
Thanks for taking the time to look, I appreciate it. I'm going to go
ahead with it now; that first thread just had me worried there might
have been something about transfer's caching behavior that I had
overlooked.
Thanks again,
Chris
On Mar 1, 8:16 pm, Bob Silverberg wrote:
> Chris,
>
>
Chris,
I just read through those threads and I don't think that either of
them suggest that there would be an issue with the cache using the
implementation of single table inheritance that I described.
I did discuss the idea/implementation with Mark, and he didn't see any
potential pitfalls. He
Hi Bob,
The specific post I'm referring to is here:
http://groups.google.com/group/transfer-dev/msg/203ace509ed70f69
There is also another post by Mark that says you should _generally_
have only one TO per table:
http://groups.google.com/group/transfer-dev/msg/f68a829a19fb4726
I've seen your bl
Just back from a week in Jamaica, hence the late reply ;-)
I did an experiment in which I was able to implement a form of single
table inheritance using Transfer, which I wrote about on my blog. I
did not foresee any problems with the cache, so I'm not sure to what
you are referring. Do you hav
10 matches
Mail list logo
