It's interesting that you advice Eric not to replace the list, because we just experience the same issue and this is actually what make it worked!
I found out that they might be a bug when committing the transaction as the size of the list is correct before committing it. The problem is that Castor stores the "to be remove" items and "to be added" in specific attributes of its Collection implementation that it has return when asking for the detail items list. When committing the transaction, Castor removes the items on its "to be remove" list and this is when the items of the "to be added" list disappear! I just found this and I'm not sure where the problem is. What I realize if that if you use a new list and populate it with the current items you wants to keep and the ones you wants to add, it works for us! Does anybody know if it's a known bug? Patrice -----Original Message----- From: Nick Stuart [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 4:37 PM To: [email protected] Subject: Re: [castor-user] JDO: 1:M problem You are going to run into problems if you simply replace the whole list. If you can, try and simply add and remove straight from the list itself. I usually always have add/remove methods in my objects that have 1:M relations in them to help this. Castor keeps track of the dependent objects back in the cahce, so replacing the list will lead to unexpected results, as you have discovered. :) You should be save wiping the list out (removeAll()) and adding other objects to it, but just dont replace the list itself. -Nick On 6/21/05, Eric Anderson <[EMAIL PROTECTED]> wrote: > > This may be my problem. The objects are actually created by struts on > form submition. I mearly replace the ArrayList with the new one created. > I know the timestamps won't match, but that shouldn't matter. Shouldn't > it delete all previous ones, and recreate new ones ? > > ie > > //receive the form > > > SiteCareForm sForm = (SiteCareForm) form; > > //retrive previous castor version of the form > > SiteCareForm s2Form = session.getAttribute("myForm); > > s2Form.setDates(sForm.getDates); > > update(s2Form); > > // then store form to session > > session.setAttribute(s2Form); > > > > ? > > > > > > > > > > > > > > >>> [EMAIL PROTECTED] 06/21/05 2:16 PM >>> > Eric, > > can you please show me a code fragment that shows us how you are > calling > Castor to e.g. delete the objects and add some others from/to the > collection ? > > Thanks > Werner > > Eric Anderson wrote: > > I have a problem with a one to many relationship. I have one object > that > > has an arraylist (1:M). This is the problem. > > > > The first time I save that object lets say with 10 objects in the > > arraylist, it saves 10 rows. If I delete all objects in the > arraylist > > and add 3 do an update, I end up with 13 rows, not 3. If I reduce it > to > > 0 and do an update, I end up with no rows (no matter how many I had > in > > there...). > > > > Anyone know why? Here is my mapping file. > > > > <class name="org.usiis.struts.SiteCareForm" identity="vaccineId"> > > <map-to table="WWW_SITE_CARE"/> > > <cache-type type="count-limited"/> > > <field name="dateVaersSubmitted" type="date" ><sql > > name="date_vaers_submitted" type="date" dirty="ignore"/></field> > > <field name="notes" type="string" ><sql name="notes" > type="char" > > dirty="ignore"/></field> > > <field name="permMedicalRec" type="string" ><sql > > name="perm_medical_rec" type="char" dirty="ignore"/></field> > > <field name="recievedMedicalCare" type="string" ><sql > > name="received_medical_care" type="char" dirty="ignore"/></field> > > <field name="treatmentDate" type="date" > <sql > > name="treatment_date" type="date" dirty="ignore"/></field> > > <field name="vaccineId" type="integer" ><sql name="vaccine_id" > > type="integer" dirty="ignore"/></field> > > <field name="vaersSubmitted" type="string" ><sql > > name="vaers_submitted" type="char" dirty="ignore"/></field> > > > > <field name="dates" type="org.usiis.struts.SiteCareDatesForm" > > collection="arraylist"> <sql many-key="vaccine_id"/> </field> > > <field name="vaccine" type="org.usiis.struts.VaccinationForm"> > > <sql name="vaccine_id" dirty="ignore" read-only="true"/> </field> > > > > </class> > > > > <class name="org.usiis.struts.SiteCareDatesForm" identity="vaccineId > Id > > eventDate" depends="org.usiis.struts.SiteCareForm" > > > <map-to table="WWW_SITE_CARE_DATES"/> > > <cache-type type="count-limited"/> > > <field name="eventDate" type="date"><sql name="event_date" > > type="date" dirty="ignore"/></field> > > <field name="Id" type="integer"><sql name="ID" > > type="integer"/></field> > > <field name="vaccineId" type="integer"><sql name="vaccine_id" > > type="integer"/></field> > > </class> > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please > > send an empty message to the following address: > > > > [EMAIL PROTECTED] > > ------------------------------------------------- > > > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ____________________________________________________________ This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Asset Management Systems SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
