Eric, once the bug has been submitted, Jira offers you to look at 'recently created' bugs via one of the preset filter links on the right side of the main window at http://jira.codehaus.org/browse/CASTOR.
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10891&createdPrevious=604800000&sorter/field=created&sorter/order=DESC Regards Werner Eric Anderson wrote: > Please let me know what the bug number is too, im intrested! > > >>>>[EMAIL PROTECTED] 06/29/05 12:27 PM >>> > > Patrice, > > if you think that there's a bug with Castor and the way it handles lazy > loaded collections (assuming this is what we are talking about), can I > please ask you to first create a Jira issue and explain the problem, and > attach a JUnit test case that allows us to replay your problem. > > Simply have a look at the bug submission guidelines for advice on what > to include in your attachments. > > Regards > Werner > > Nick Stuart wrote: > >>That sounds like a bug to me. Objects sound just be walking off on >>their own if they need to get added to the database (or removed). Care >>to open a bug report on JIRA with a possible test case and/or more >>indepth example? >> >>Another question thats missed, are these collections lazy loaded? It >>sounds like they might be if you are using Castors Collection >>implementation, so that might be another wrinkle in the details. >> >>-Nick >> >>On 6/29/05, Patrice Jaton <[EMAIL PROTECTED]> wrote: >> >> >>>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] >>>------------------------------------------------- >>> >>> > > > > ------------------------------------------------- > 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] -------------------------------------------------
