Just trying to make sure I'm understanding this particular thread. I
have a table that has a "hasOne" relationship with another table. I
understand when doing a "CreateRecord" how the relationships work. It
looks like it does not work when doing a "CreateGateway". Right now, if
I want to display a listing, I have to create query joining the two
tables with what I need, then do at getAll() -- by the way I love
getAll(), it makes having sortable tables so easy. I would have thought
you would have the same relationship strategy as with Create Record.
Am I understanding this correctly?
Byron
Doug Hughes wrote:
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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
