Regarding the iterator index and the reset.  I have tried various methods, including calling reset then doing a loop with condition hasMore().   For this particular test though, I knew the user had a single LoanApplication so I was referring to it at element 1.   Those are good points though, and yes the UserAccount is in the session scope.

Regarding update vs save:
I am able to do the initial save when I first build the object.  The problem lies when I later modify one of the child properties and do a save() on the top most parent.  It neither updates or creates a new record.

Thanks for your input Doug.

~Dave

On 8/8/06, Doug Sims <[EMAIL PROTECTED]> wrote:
Have you tried calling .reset() on your loanApplicationIterator? or
maybe the useraccount object is in a persistent scope and the iterator
is not being refreshed

Just curious, Are you always using getat(1) on your Iterator, or are
you looping through? Also last straw attempt:are you sure the problem
isn't that an existing record is being updated when calling save,
rather than a new one?
Doug S.
evenamonkey.com

On 8/8/06, Dave Shuck <[EMAIL PROTECTED]> wrote:
> oops... forgot to include that in the email:
>
>         <object name="URLA_SETUP" alias="UrlaSetup">
>
>             <field name="REFERENCE_ID" alias="ReferenceId" />
>              <field name="COMPANY_CODE" alias="CompanyCode" />
>             <field name="URLA_ID" alias="UrlaId" />
>
>             <hasOne name="ReferenceInfo">
>
>                 <relate from="ReferenceId" to="ReferenceId" />
>                 <relate from="CompanyCode" to="CompanyCode" />
>             </hasOne>
>         </object>
>
> Thanks...
>
> ~Dave
>
>
> On 8/8/06, Kevin Roche <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Don't you need to have an object for UrlaSetup?
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ]On
> Behalf Of Dave Shuck
> > Sent: 08 August 2006 15:34
> > To: [email protected]
> > Subject: [Reactor for CF] Strange issue with updating child objects
> >
> > I have a very non-standard database that I have to work with for a loan
> origination system.  Many of the legacy tables that I am forced to work with
> have multiple non-self incrementing primary keys.  I have added a few new
> tables that allow me to have a handle on the legacy stuff.
> >
> > When I am inserting data for the first time, I have no problem using the
> iterator.add() methods and adding 1:1 child objects using reactor.  It
> creates the relationships which are then saved to the database without
> issue.  My lowest level in the hierarchy of the current issue looks like
> this:
> >
> >
> UserAccount.getLoanApplicationIterator ().getAt(1).getReferenceInfo().getUrlaSetup().setSomething("my
> value");
> >
> > On creating/inserting, this all works exactly as planned.  The UserAccount
> record is then available through a UserAccount facade.
> >
> > Later when I want to change a value and save, I have no problem at all
> changing and outputting any property, but when it comes time to do
> UserAccount.save(), no data actually gets persisted to the database.  There
> is no error, but simply no database action.  I have tried shooting at this
> from a number of angles, but would really appreciate a second opinion before
> I have to scrap this direction and try something else altogether.
> >
> > The tables that are in play with this particular problem are listed below.
>
> >
> > UserAccount: (new table)
> > UserAccountId - self incrementing PK
> > Username...Password... etc....
> >
> > LoanApplication: (new table)
> > LoanApplicationId - self incrementing PK
> > reference_id -  legacy FK ColdFusion UUID
> > company_code - legacy FK numeric
> >
> > UserAccountLoanApplication: (new table)
> > UserAccountLoanApplicationId: self incrementing PK
> > UserAccountId: FK to UserAccount
> > LoanApplicationId: FK to LoanApplication:
> >
> > now the legacy stuff...
> >
> > REFERENCE_INFO
> > REFERENCE_ID - non-self incrementing part of multi-PK varchar
> > COMPANY_CODE - non-self incrementing part of multi-PK numeric
> > various other badly named columns...
> >
> > URLA_SETUP:
> > REFERENCE_ID - non-self incrementing part of multi-PK varchar
> > COMPANY_CODE - non-self incrementing part of multi-PK numeric
> > URLA_SETUP_ID - part of multi-PK but always a "1" for some reason....
> > various other badly named columns...
> >
> > So here is the config that ties this together, although I am stripping the
> non-key fields for clarity:
> >
> > <object name="UserAccount">
> >     <hasMany name="LoanApplication">
> >         <link name="UserAccountLoanApplication" />
> >     </hasMany>
> > </object>
> >
> >
> > <object name="LoanApplication">
> >     <field name="company_code" alias="CompanyCode" />
> >     <field name="reference_id" alias="ReferenceId" />
>
> >
> >     <hasOne name="ReferenceInfo">
> >         <relate from="CompanyCode" to="CompanyCode" />
> >         <relate from="ReferenceId" to="ReferenceId" />
> >     </hasOne>
> >     <hasMany name="UserAccount">
> >         <link name="UserAccountLoanApplication" />
> >     </hasMany>
> > </object>
> >
> > <object name="UserAccountLoanApplication">
> >     <hasOne name="UserAccount">
> >         <relate from="UserAccountId" to="UserAccountId" />
> >     </hasOne>
> >     <hasOne name="LoanApplication">
> >         <relate from="LoanApplicationId" to="LoanApplicationId" />
> >     </hasOne>
> > </object>
> >
> >
> >
> > <object name="REFERENCE_INFO" alias="ReferenceInfo">
> >     <field name="REFERENCE_ID" alias="ReferenceId" />
> >     <field name="COMPANY_CODE" alias="CompanyCode" />
> >
> >     <hasOne name="UrlaSetup">
> >         <relate from="ReferenceId" to="ReferenceId" />
> >         <relate from="CompanyCode" to="CompanyCode" />
> >     </hasOne>
> > </object>
> >
> >
> > For what it is worth, I can instantiate an existing ReferenceId object and
> modify/persist values in its child UrlaSetup object like this:
> >
> > ReferenceInfo.getUrlaSetup().setSomething("my value");
> > ReferenceInfo.save();
> >
> > But for some reason I cannot save from above that level.  If anyone has
> any thoughts on this matter, I would really appreciate hearing them.  Also
> if I need to clarify any of the above, just ask.  I really need to find
> resolution to this issue!
> >
> >
> > --
> > ~Dave Shuck
> > [EMAIL PROTECTED]
> > www.daveshuck.com
> > www.worldwildweb.biz
> > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- --
> > 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/
> > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- --
>
>
>
> --
> ~Dave Shuck
> [EMAIL PROTECTED]
> www.daveshuck.com
>   www.worldwildweb.biz
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- --
> 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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --




--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
www.worldwildweb.biz
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Reply via email to