Doug do you have any plans to support more than one database per reactor instance or foreign keys on linked databases?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes Sent: Friday, July 21, 2006 2:25 PM To: [email protected] Subject: RE: (LONG) Re: [Reactor for CF] SharedKey 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/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
