I think there is a communications problem. I downloaded the patch and tried it. It doesn't work as expected.
The original problem was that it would try to delete an object that wasn't in the database and throw an exception. So, the patch checks if the object isn't in the database and if it isn't, it throws an exception. We are right back where we started. Thank you for the nicer exception, but we don't want it to throw an exception. I've patched your patch for us to just throw away the PersistenceBrokerException that assertValidPkForDelete throws, but I don't think it's a good long term solution for us to use a patched version of OJB in our app. What is wrong with checking to see if the row is in the table, if so, delete it, if not ignoring it? Thanks Jay On 4/18/05, Jay Sissom <[EMAIL PROTECTED]> wrote: > Thank you > Jay > > On 4/18/05, Armin Waibel <[EMAIL PROTECTED]> wrote: > > 1.0.x is OJB_1_0_RELEASE branch > > > > Armin > > > > Jay Sissom wrote: > > > Should I get a particular branch to get the 1.0.x CVS code or should I > > > get HEAD? > > > > > > Thanks > > > Jay > > > > > > > > > On 4/17/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > > > > > >>hi jay, > > >> > > >>this fix is in cvs 1.0.x and 1.1 > > >> > > >>jakob > > >> > > >>Jay Sissom schrieb: > > >> > > >>>Thanks. I'm working on a patch. When I get it working, I'll send it > > >>>so you can evaluate it. > > >>> > > >>>Jay > > >>> > > >>> > > >>>On 4/16/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > > >>> > > >>> > > >>>>hi jay, > > >>>> > > >>>>i opened an issue in jira http://issues.apache.org/jira/browse/OJB-23 > > >>>> > > >>>>jakob > > >>>> > > >>>>Jakob Braeuchi schrieb: > > >>>> > > >>>> > > >>>>>hi jay, > > >>>>> > > >>>>> > > >>>>>Jay Sissom schrieb: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>I understand that, but shouldn't it NOT delete items that were never > > >>>>>>in the database? In my code example below, I add something to the > > >>>>> > > >>>>> > > >>>>>the problem is, tat ojb does not have an internal state to track > > >>>>>whether > > >>>>>the object is persistent or not. > > >>>>> > > >>>>> > > >>>>> > > >>>>>>list that never was in the database, then OJB tries to delete it > > >>>>>>anyway. How can it delete something when the primary key is null? > > >>>>> > > >>>>> > > >>>>>we could try to check the pk for null values (primitive pk are still a > > >>>>>problem) before adding an object to the deleted-list. > > >>>>> > > >>>>>jakob > > >>>>> > > >>>>> > > >>>>> > > >>>>>>On 4/15/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>hi jay, > > >>>>>>> > > >>>>>>>this is a feature of the RemovalAwareCollection. it tries to delete > > >>>>>>>all > > >>>>>>>removed items from the database. > > >>>>>>> > > >>>>>>>jakob > > >>>>>>> > > >>>>>>>Jay Sissom schrieb: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>Hello, we have a mapping with a 1:m relation in it: > > >>>>>>>> > > >>>>>>>><class-descriptor class="edu.iu.uis.pur.req.bo.Requisition" > > >>>>>>>>table="PUR.PUR_REQS_T"> > > >>>>>>>><field-descriptor column="REQS_ID" jdbc-type="INTEGER" name="id" > > >>>>>>>>primarykey="true" > > >>>>>>>> sequence-name="PUR.REQS_ID" autoincrement="true"/> > > >>>>>>>>... many other fields ..... > > >>>>>>>><field-descriptor column="VER_NBR" jdbc-type="INTEGER" > > >>>>>>>>locking="true" > > >>>>>>>>name="version"/> > > >>>>>>>><collection-descriptor auto-retrieve="true" auto-update="object" > > >>>>>>>>auto-delete="object" proxy="true" > > >>>>>>>> element-class-ref="edu.iu.uis.pur.req.bo.RequisitionItem" > > >>>>>>>>name="items"> > > >>>>>>>> <inverse-foreignkey field-ref="requisitionId"/> > > >>>>>>>></collection-descriptor> > > >>>>>>>></class-descriptor> > > >>>>>>>> > > >>>>>>>><class-descriptor class="edu.iu.uis.pur.req.bo.RequisitionItem" > > >>>>>>>>table="PUR.PUR_REQS_ITM_T"> > > >>>>>>>><field-descriptor column="REQS_ID" jdbc-type="INTEGER" > > >>>>>>>>name="requisitionId" primarykey="true"/> > > >>>>>>>><field-descriptor column="ITM_LN_NBR" jdbc-type="INTEGER" > > >>>>>>>>name="itemLineNumber" primarykey="true"/> > > >>>>>>>> ....many other fields... > > >>>>>>>><field-descriptor column="VER_NBR" jdbc-type="INTEGER" > > >>>>>>>>locking="true" > > >>>>>>>>name="version"/> > > >>>>>>>></class-descriptor> > > >>>>>>>> > > >>>>>>>>There are times in our process where we add a new item to the items > > >>>>>>>>collection in our Requisition, then we delete it before saving the > > >>>>>>>>collection. > > >>>>>>>> > > >>>>>>>>When we do this, we get an OptimisticLockException because OJB is > > >>>>>>>>trying to delete the object that was never in the table. Here is > > >>>>>>>>sample code that causes this: > > >>>>>>>> > > >>>>>>>>Requisition req = reqService.getRequisitionById(new Integer(1517)); > > >>>>>>>> > > >>>>>>>>// Add a blank one > > >>>>>>>>RequisitionItem ri = new RequisitionItem(); > > >>>>>>>>req.getItems().add(ri); > > >>>>>>>> > > >>>>>>>>// Remove it > > >>>>>>>>req.getItems().remove(ri); > > >>>>>>>> > > >>>>>>>>broker.store(req); > > >>>>>>>> > > >>>>>>>>Is this because of something we are doing or is it a bug? We're > > >>>>>>>>using > > >>>>>>>>version 1.0.0. > > >>>>>>>> > > >>>>>>>>Thanks > > >>>>>>>>Jay > > >>>>>>>> > > >>>>>>>>--------------------------------------------------------------------- > > >>>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>>--------------------------------------------------------------------- > > >>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>>--------------------------------------------------------------------- > > >>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>>>> > > >>>>>> > > >>>>> > > >>>>>--------------------------------------------------------------------- > > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>>> > > >>>>> > > >>>> > > >>>>--------------------------------------------------------------------- > > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>> > > >>>> > > >>> > > >>> > > >>>--------------------------------------------------------------------- > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > >> > > >>--------------------------------------------------------------------- > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
