RE: [Reactor for CF] Link relationship modelling question

[Doug Hughes]

Try :   UserRecord.getSeatIterator().getAt(2).getParent().getPRIMARY_FLAG()   Doug     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Newby Matthew S CONT PORT Sent: Friday, June 16, 2006 12:14 PM To: 'reactor@reactorframework.com' Subject: RE: [Reactor for CF] Link relationship modelling question   As soon as I'm able to get off Oracle 8i I'll be able to try out the getParent() function.  Looks like my migration got pushed back to late July.  :-(  I'm not quite sure how to reference it though.  If I call the getQuery() method, I get back a query, not objects.  Are the objects only available in the getArray() method?  So, if I wanted to get the PRIMARY_FLAG value for the second seat assigned to a user, would it be something like:  UserRecord.getSeatIterator().getArray()[2].getParent().getPRIMARY_FLAG()?     The alias attribute looks like it's doing the job -- now I can retrieve different sets of related requests, depending on whether I am just the requester, or am the originator, or supervisor.  Thanks for the info, Doug!  I took a look through the Word doc version of the documentation from b273, and the FlashHelp version from b281 and didn't see any reference to this attribute.  Is it documented yet?  The alias attribute is also helpful for taking the all-uppercase table names and getting iterators that can be typed as headlessCamelCaps (getSeatIterator for instance), which is definitely easier on the fingers when coding...  :-)   -matt   Matthew Newby PNS Web Services PH: 207-438-5263 email: [EMAIL PROTECTED] When digitally signed, the signature is in accordance with DoDI 8520.2, dated 1 Apr 2004. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Doug Hughes Sent: Friday, June 16, 2006 11:01 AM To: reactor@reactorframework.com Subject: RE: [Reactor for CF] Link relationship modelling question   From an object in the iterator you can call getParent().  That will return the "parent" record in the linking table, the record that links the user to seats.   For the getREQUEST_MAINLUIterator has been declared twice in the same file error you'll need to define an alias on at least one of the <hasMany name="REQUEST_MAINLU"> tags.  For example:   <!-- How do I relate the multiple people embedded in each request? --> <hasMany name="REQUEST_MAINLU" alias="requester">     <relate to="REQUESTER_SA_ID" from="USER_SA_ID"/> </hasMany> <hasMany name="REQUEST_MAINLU" alias="originator">     <relate to="ORIGINATOR_SA_ID" from="USER_SA_ID"/> </hasMany> <hasMany name="REQUEST_MAINLU">     <relate to="SUPERVISOR_SA_ID" from="USER_SA_ID"/> </hasMany>   Now you'll have getRequersterIterator and getOriginatorIterator on you object.   Doug     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Newby Matthew S CONT PORT Sent: Friday, June 16, 2006 10:53 AM To: 'reactor@reactorframework.com' Subject: RE: [Reactor for CF] Link relationship modelling question   Hmmm... what I'm trying to get at is that there is a relationship between users and seats, but there's more information in the linking table than just the fact that the two are related - the user has many seats, but she "has" them in different ways.  So, on a person report, I loop over all the seats associated with the person organizing the output so that the seats the user is primary on show up first.  The nature of the relationship between these two objects is embedded in the linking table.  From what I can see, when I use the hasMany-link syntax the iterator appears to make the linking table transparent; I don't know how to get data out of it.  When I use the hasMany-relate syntax, the iterator retrieves information from the related table.   Another question about link relationships:  One of the major functions my app performs is facilitating requests for applications by users (or by user agents on behalf of a user).  So, I have a request object that's related to the user table a few different ways.  The request table has three foreign keys pointing back at the users table, one for the requester, one for the originator, and one for the supervisor (supervisors change quite frequently here, so that relationship is tracked in the request, rather than in the user object).  So in my reactor.xml config file I put the following: <!-- How do I relate the multiple people embedded in each request? --> <hasMany name="REQUEST_MAINLU">     <relate to="REQUESTER_SA_ID" from="USER_SA_ID"/> </hasMany> <hasMany name="REQUEST_MAINLU">     <relate to="ORIGINATOR_SA_ID" from="USER_SA_ID"/> </hasMany> <hasMany name="REQUEST_MAINLU">     <relate to="SUPERVISOR_SA_ID" from="USER_SA_ID"/> </hasMany> But, this doesn't work, as it throws a "getREQUEST_MAINLUIterator has been declared twice in the same file" error.  However this is a legitimate relationship - a given user may have made multiple requests, originated multiple requests, and been a supervisor for multiple requests.   Thoughts?   -matt   Matthew Newby PNS Web Services PH: 207-438-5263 email: [EMAIL PROTECTED] When digitally signed, the signature is in accordance with DoDI 8520.2, dated 1 Apr 2004. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Doug Hughes Sent: Friday, June 16, 2006 9:42 AM To: reactor@reactorframework.com Subject: RE: [Reactor for CF] Link relationship modelling question So, if I understand you, you want to filter the results in the seatIterator based on criteria from other relationships?    I think I'd handle this by creating a custom method which gets the seatIterator and uses the iterator's getWhere() method (which is actually an OO query where object) to filter the results.    Doug   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Newby Matthew S CONT PORT Sent: Friday, June 16, 2006 9:30 AM To: 'reactor@reactorframework.com' Subject: [Reactor for CF] Link relationship modelling question   I see from the syntax described in the docs how to relate two tables with a link table in between.  I'm wondering how you go about modelling things when that link includes additional information than just the fact that the two main objects are related...  An example is in order:  In my post about Oracle a couple days ago, I described the user object which hasOne user status, hasMany network accounts, and is linked to user roles.  This same user object is also linked to a seat object, however, there's additional information in the user to seat linking table, such as a date/time stamp indicating when the user was assigned that seat, and a primary flag indicating that this user is the primary user (as opposed to someone who just uses the seat but isn't responsible for the software that's on it).  Is there a way to relate these three tables in Reactor such that the additional information is also available in the iterator, or some other convenient place?  The link tag seems to drop a usable reference to the intermediate table...  Please forgive me if I've missed something obvious in the docs.   Thanks!   -matt     Matthew Newby PNS Web Services PH: 207-438-5263 email: [EMAIL PROTECTED] When digitally signed, the signature is in accordance with DoDI 8520.2, dated 1 Apr 2004.   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List reactor@doughughes.net Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --