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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
