Do you mean on gateways? Yea. Why wouldn't I? Doug
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Byron Raines Sent: Friday, July 21, 2006 7:25 PM To: [email protected] Subject: Re: (LONG) Re: [Reactor for CF] SharedKey Doug, Will this allow the use of getAll( ) for this situation? byron Doug Hughes wrote: > Chris, > > This will probably be depricated or removed in 2.0. In 2.0 I plan to allow > you to define objects which extend beyond one table. So, in your case you > could define a consultant which is made up of the Consultant and User > tables. That should be easier than this shared key nonsense and help > improve performance in general. > > Doug > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christopher Bradford > Sent: Friday, July 21, 2006 2:00 PM > To: [email protected] > Subject: (LONG) Re: [Reactor for CF] SharedKey > > Results! :-) > > I tried the code in the docs and was completely shocked to see that it > worked. :-p Well, turns out that it didn't *really* work; it only sort of > worked. The problem is when there is more than one hasOne relationship > between to same two tables. For example: > > TABLE: User > ID int PK identity > sponsorID int FK to Consultant.userID > > TABLE: Consultant > userID int PK FK to User.ID > > In Reactor, User has two relationships to Consultant: > > <object name="user"> > <!-- Consultant is a User --> > <hasOne name="consultant"> > <relate from="ID" to="userID" /> > </hasOne> > > <!-- User has a Sponsor --> > <hasOne name="consultant" alias="sponsor"> > <relate from="sponsorID" to="userID" /> > </hasOne> > </object> > > <object name="consultant"> > <!-- Consultant is a User --> > <hasOne name="user"> > <relate from="userID" to="ID" /> > </hasOne> > </object> > > The question was where to put the sharedKey attribute. The docs say to put > it on the consultant object. I did that (<object name="consultant" > sharedKey="true">). My XML editor complained, because the DTD doesn't allow > for this, but ModelGlue worked. I was able to create a consultant object, > get its user, set properties on both, and save. However, I wondered whether > Consultant was able to distinguish between the "is-A" relationship > (Consultant is a User) and the "has-A" relationship (User has a Sponsor). > When I created a new Consultant object and set the Sponsor on its User to > the previously created Consultant, Reactor overwrote the initial record. > This suggests that putting the sharedKey on the object tag does not > distinguish between different hasOne relationships. > > So, I moved the sharedKey attribute to the hasOne tag inside the Consultant > object (<hasOne name="user" sharedKey="true">). This time, SQL Server > complained about a foreign key violation. Turns out Reactor was saving the > Consultant first, which won't work. > > Finally, I moved the sharedKey attribute to the first hasOne tag inside the > User object (<hasOne name="consultant" sharedKey="true">) -- the one > representing an "is-a" relationship. This worked perfectly. I was able to > create a new Consultant, get its User, set properties on both, and set the > Sponsor without overwriting the earlier records. > > So, it seems the best place is to put the sharedKey="true" in the base > object's hasOne tag that refers to the extending object. > > I wonder whether it doesn't make just as much sense, and would be clearer, > to add an "isA" tag in Reactor v2? > > Hopefully this is clear and helpful. > > Christopher Bradford > Alive! LLP > > ----- Original Message ----- > From: "Doug Hughes" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Friday, July 21, 2006 7:27 AM > Subject: SPAM-LOW: RE: [Reactor for CF] SharedKey > > > >> You know, this smells funny, doesn't it? >> >> Chris - give it a try with the code in the docs. If that doesn't work >> move >> the shared key to the relationship (where it seems it belongs) and try >> that. >> >> >> Plz report back and let us know if the docs are fubared. >> >> Doug >> > > > > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
