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 the same employee as both a Designer and an Employee (i.e. the subclass and superclass). 3. You hang on to a transfer object for long enough for it to expire out of the cache, and then ask transfer to load it again. I mention this for completeness, it's not related to STI at all. If you do any of those things, you get two separate objects mapped to a single database record. Transfer has no awareness that the two are related and therefore will not manage the relationship for you. Transfer's caching works to spec, but you've basically stepped outside the spec. The simplest way to stay safe is to map any table only once, which is the general advice. However, Bob and Paul have provided a nice mechanism to at least strongly discourage scenario #1. You can side-step #2 by simply not mapping an Employee class, but you then need to hand-code anything that relates to all employees. All of that stuff is what Mark refers to when he says you have to "manage it well". If you map a table more than once without understanding all this then you're certainly headed for trouble. As for #3, this is one of the reasons that storing transfer objects in session or application scopes is to be avoided. Jaime On Mon, Mar 2, 2009 at 12:06 PM, achebe <[email protected]> wrote: > > 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 <[email protected]> wrote: > > 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 did point out, however, that a number of forms > > of inheritance, including single table inheritance, are on the roadmap > > for a future version of Transfer. I imagine that whatever Mark ends > > up implementing will be far more flexible and elegant that what Paul > > and I came up with - if you are in a position to wait for it. > > > > Cheers, > > Bob > > > > > > > > On Sun, Mar 1, 2009 at 10:46 AM, achebe <[email protected]> wrote: > > > > > 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 blog post on STI and a couple of posts on the list > > > where other people where successfully using it and I can't see any > > > issues with it either. > > > > > Thanks, > > > Chris > > > > > On Mar 1, 10:25 am, Bob Silverberg <[email protected]> wrote: > > >> 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 have any links to the posts that you read > > >> that suggest this can be a problem? > > > > >> Cheers, > > >> Bob > > > > >> On Thu, Feb 26, 2009 at 1:34 PM, achebe <[email protected]> > wrote: > > > > >> > I've seen a few posts on Single Table Inheritance where it's been > > >> > mentioned that it can be done but that it is difficult because of > the > > >> > need to manage the transfer cache and I was hoping someone could > shed > > >> > a little light on what specific issues there are to look out for? > > > > >> -- > > >> Bob Silverbergwww.silverwareconsulting.com > > > > -- > > Bob Silverbergwww.silverwareconsulting.com > > > --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
