RE: Final release?

From: Gentry, Michael \(Contractor\) ("Gentry,)
Date: Tue Jul 11 2006 - 10:31:58 EDT

  • Next message: Andrus Adamchik: "Re: Final release?"

    OK, I now have a standalone test. The original application would throw
    an exception with a Sybase backend. My test case throws the same
    exception with a PostgreSQL backend, so we can eliminate the binary key
    wackiness from the equation. My gut feeling is inheritance has
    something to do with it, since my non-inheritance test didn't fail, but
    it is only a gut feeling.

    Would you like a tarball of it? I can look into it, too.

    Thanks,

    /dev/mrg

    -----Original Message-----
    From: Andrus Adamchik [mailto:andru..bjectstyle.org]
    Sent: Saturday, July 08, 2006 2:05 PM
    To: cayenne-de..ncubator.apache.org
    Subject: Re: Final release?

    Mike, would it be possible to create a small standalone unit test to
    reproduce this?

    Andrus

    On Jul 7, 2006, at 3:46 PM, Gentry, Michael ((Contractor)) wrote:

    > I hate to be a party pooper, but I have another concern ...
    >
    > Now that I can insert again (thanks!), I run into this problem.
    > Given:
    >
    > CollectionElement ->> Item <<- Notification
    >
    > If I insert an Item (it is just a many-to-many linkage table) in one
    > request, and then immediately delete it again in the next request,
    > I am
    > getting optimistic locking exceptions. If I restart the app, I can
    > then
    > go in and delete it. Here are some of the logs when doing the delete:
    >
    >
    > item (starting out):
    > PID=0x00000000000000225c85a35e]{<ObjectId:PSEnumeratedItem,
    > identifier=[..d5543>; committed;
    > [collectionElement=>{<ObjectId:PSLocalCollectionElement,
    > identifier=[..6c157>}; moniker=>ES;
    > notification=>{<ObjectId:FENotification, identifier=[..36b89>}]}
    >
    > collectionElement.removeFromItems(item);
    > [PID=0x00000000000000225c85a35e]{<ObjectId:PSEnumeratedItem,
    > identifier=[..d5543>; modified; [collectionElement=>null;
    > moniker=>ES;
    > notification=>{<ObjectId:FENotification, identifier=[..36b89>}]}
    >
    > notification.removeFromItems(item);
    > [PID=0x00000000000000225c85a35e]{<ObjectId:PSEnumeratedItem,
    > identifier=[..d5543>; modified; [collectionElement=>null;
    > moniker=>ES;
    > notification=>null]}
    >
    > dataContext.deleteObject(item);
    > [PID=0x00000000000000225c85a35e]{<ObjectId:PSEnumeratedItem,
    > identifier=[..d5543>; deleted; [collectionElement=>null; moniker=>ES;
    > notification=>null]}
    >
    > dataContext.commitChanges();
    > org.objectstyle.cayenne.access.QueryLogger - DELETE FROM PS_Item
    > WHERE
    > identifier = ? AND elementPID IS NULL AND moniker = ? AND objectPID IS
    > NULL
    > org.objectstyle.cayenne.access.QueryLogger - [bind: < 00 00 00 00
    > 00 00
    > 00 22 5C 85 A3 5E >, NULL, 'ES', NULL]
    > org.objectstyle.cayenne.access.QueryLogger - *** error.
    > org.objectstyle.cayenne.access.OptimisticLockException: [v.1.2M12
    > March
    > 23 2006] Optimistic Lock Failure, SQL: [DELETE FROM PS_Item WHERE
    > identifier = ? AND elementPID IS NULL AND moniker = ? AND objectPID IS
    > NULL], WHERE clause bindings: [moniker='ES', identifier=< 00 00 00
    > 00 00
    > 00 00 22 5C 85 A3 5E >, objectPID=NULL, elementPID=NULL]
    >
    >
    > Ignore the 1.2M12 -- I'm running against the latest from Subversion
    > within Eclipse (guess that M12 the last time I did a full build using
    > ant). The bind output is also misleading -- 4 values for 2 ?'s (I
    > thought I fixed that at one point, but maybe that was for UPDATE
    > only).
    > Anyway, this code used to work in 1.2M9 (and earlier). I use
    > optimistic
    > locking on everything, but there are no cascade/etc delete rules.
    >
    > I'll experiment/debug more, just thought I'd report it in case you
    > were
    > trying to put out the release.
    >
    > Thanks!
    >
    > /dev/mrg
    >
    > -----Original Message-----
    > From: Andrus Adamchik [mailto:andru..bjectstyle.org
    > <mailto:andru..bjectstyle.org> ]
    > Sent: Thursday, July 06, 2006 10:33 AM
    > To: cayenne-de..ncubator.apache.org
    > Subject: Re: Final release?
    >
    >
    > Let's at least submit this as a bug. I think I may have an older
    > Linux box where I can put Sybase and play with a solution that I had
    > in mind.
    >
    > In any event whatever fix we end up with, it should be possible to
    > stick it in a custom PkGenerator, so it shouldn't be a problem for
    > 1.2 users if it goes in release 3.0 (and we can port it to 1.2.1 as
    > well).
    >
    > Andrus
    >
    > On Jul 6, 2006, at 10:16 AM, Gentry, Michael ((Contractor)) wrote:
    >> My biggest concern right now is the Sybase PK question. If I can get
    >> our DBA (who is out right now) to set me up a playground somewhere,
    >> I'll
    >> test it. Of course, we could decide to handle that as a bug fix,
    >> too.
    >> Either way, I won't be upgrading past M9 for a bit ...
    >>
    >> Thanks,
    >>
    >> /dev/mrg
    >>
    >>
    >>
    >> -----Original Message-----
    >> From: Andrus Adamchik [mailto:andru..bjectstyle.org
    > <mailto:andru..bjectstyle.org> ]
    >> Sent: Tuesday, July 04, 2006 11:07 AM
    >> To: cayenne-de..ncubator.apache.org
    >> Subject: Final release?
    >>
    >>
    >> I think it's time to make the final release of 1.2 and move ahead
    >> with other things that we planned. I am working on finishing the
    >> documentation (namely remote object persistence tutorial), and fixing
    >> last minute bugs. I think we are in a good shape overall. So how
    >> about a release sometime early next week.
    >>
    >> Comments? Objections?
    >>
    >> Andrus
    >>
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Tue Jul 11 2006 - 10:32:32 EDT