Thanks, Teddy. I'd appreciate it if you would send me a code snippet when you can. For some reason, it's just not clicking.

Byron

Teddy Payne wrote:
I don't have my reactor code on me, but to get the address information I believe there is a method called _getParent() or getParent(). It should get the parent relationship object. _getParent() should get staff and then you can create call the iterator for the Addresses.

I would give a code snippet, but that is on my system at home.

Teddy

On 7/24/06, *Byron Raines* < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Teddy,

    I understand that.  I may not be explaining myself
    correctly.  Maybe an
    example.

    Table:  Staff

    StaffID: int
    Staffrname: char(50)

    Table:  Address

    AddressID:  int
    StaffID: int
    Address1:  char(50)
    State: char (2)

    reactor.xml:
    <object name="Staff">
         <hasOne name="Address">
             <relate from="StaffID" to="StaffID" />
         </hasOne>
    </object>

    I want to display a list of staff and their address.

    If I do:

    <cfset StaffGateway = Reactor.createGateway("Staff") />
    <cfset qStaff = StaffGateway.getAll() />

    I can list all the Staff but not their address info.  It seems I
    cannot
    access their Address info unless I create a query combining the two,
    then do the "createGateway()" and "getAll().  My thinking was I should
    be able to access the address info in the same way I access it on
    a per
    record basis.

    I hope I'm explaining myself correctly.

    Byron



    Teddy Payne wrote:
    > Sorting on Create Record?  Record factory objects are typically used
    > to work with 1 record at a time.  A Gateway is for working with
    > multiple records at a time.
    >
    > I am not trying to state the obvious or chastise, but does that make
    > sense?
    >
    > Teddy
    >
    > On 7/24/06, *Byron Raines* < [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
    >
    >     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]>
    >     <mailto: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> [mailto:
    >     [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    <mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>] On
    >     > Behalf Of Byron Raines
    >     > Sent: Friday, July 21, 2006 7:25 PM
    >     > To: [email protected]
    <mailto:[email protected]>
    >     <mailto: [email protected]
    <mailto:[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]>
    >     <mailto: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>
    >     [mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >     <mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>] On
    >     >> Behalf Of Christopher Bradford
    >     >> Sent: Friday, July 21, 2006 2:00 PM
    >     >> To: [email protected]
    <mailto:[email protected]>
    >     <mailto:[email protected]
    <mailto:[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]
    <mailto:[EMAIL PROTECTED]>
    >     <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
    >     >> To: < [email protected]
    <mailto:[email protected]>
    >     <mailto:[email protected]
    <mailto:[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] <mailto:[email protected]>
    <mailto: [email protected] <mailto:[email protected]>>
    >     >> Archives at:
    >     http://www.mail-archive.com/reactor%40doughughes.net/
    >     < http://www.mail-archive.com/reactor%40doughughes.net/>
    >     >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    >     -- -- -- --
    >     >> -- --
    >     >>
    >     >>
    >     >>
    >     >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    >     -- -- -- --
    >     >>
    >     > -- --
    >     >
    >     >> Reactor for ColdFusion Mailing List
    >     >> [email protected] <mailto:[email protected]>
    <mailto:[email protected] <mailto:[email protected]>>
    >     >> Archives at:
    http://www.mail-archive.com/reactor%40doughughes.net/
    >     >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    >     -- -- -- --
    >     >>
    >     > -- --
    >     >
    >     >>
    >     >>
    >     >
    >     >
    >     > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    >     -- -- -- --
    >     > -- --
    >     > Reactor for ColdFusion Mailing List
    >     > [email protected] <mailto:[email protected]>
    <mailto:[email protected] <mailto:[email protected]>>
    >     > Archives at:
    http://www.mail-archive.com/reactor%40doughughes.net/
    >     > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    >     -- -- -- --
    >     > -- --
    >     >
    >     >
    >     >
    >     > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    >     -- -- -- -- -- --
    >     > Reactor for ColdFusion Mailing List
    >     > [email protected] <mailto:[email protected]>
    <mailto:[email protected] <mailto:[email protected]>>
    >     > Archives at:
    http://www.mail-archive.com/reactor%40doughughes.net/
    <http://www.mail-archive.com/reactor%40doughughes.net/>
    >     > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    >     -- -- -- -- -- --
    >     >
    >     >
    >
    >
    >     -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    >     -- -- -- -- --
    >     Reactor for ColdFusion Mailing List
    >     [email protected] <mailto:[email protected]>
    <mailto:[email protected] <mailto:[email protected]>>
    >     Archives at:
    http://www.mail-archive.com/reactor%40doughughes.net/
    >     -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    >     -- -- -- -- --
    >
    >
    >
    >
    > --
    > <cf_payne />
    > http://cfpayne.wordpress.com/
    > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- --
    > -- -- -- --
    > Reactor for ColdFusion Mailing List
    > [email protected] <mailto:[email protected]>
    > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
    > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    > -- -- -- --


    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- -- -- -- --
    Reactor for ColdFusion Mailing List
    [email protected] <mailto:[email protected]>
    Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
    <http://www.mail-archive.com/reactor%40doughughes.net/>
    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    -- -- -- -- --




--
<cf_payne />
http://cfpayne.wordpress.com/ <http://cfpayne.wordpress.com/>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Reply via email to