DB shouldn't matter - it is easy to switch between them, besides in my
test environment I have all of the DBs listed under
org.objectstyle.cayenne.dba
Andrus
> It's completely consistent for me. I can try to reproduce it in a
> scaled down test case. If I do, do you have a DB preference (keep in
> mind our primary keys are binary, but I can try it with more normal keys
> -- not sure if that makes a difference)?
>
> Just for grins, here is my insert code (assuming no typos), which
> essentially adds a row in a join table:
>
> // assume collection, collectionElement, and notification exist and are
> valid
> PSEnumeratedItem item (PSEnumeratedItem)
> collection.getDataContext().createAndRegisterNewObject(PSEnumeratedItem.
> class);
> item.setNotification(notification); // Set the two sides
> item.setCollectionElement(collectionElement); // of the join ...
> item.getDataContext().commitChanges();
> QueueDetails nextPage = (QueueDetails)
> cycle.getNextPage("QueueDetails");
> nextPage.reset(); // cause a reload of the data
> nextPage.reset(); // without this, cannot immediately delete the just
> inserted notification
> cycle.activate();
>
>
> Here is the reset() method (in a different Tapestry page):
>
> final Expression expression
> Expression.fromString("items.collectionElement.collection = $queuePID");
> Map map = new HashMap(1);
> map.put("queuePID", HexCoder.decode(getQueueIdentifier()));
> SelectQuery query = new SelectQuery(FENotification.class,
> expression.expWithParameters(map));
> query.addOrdering("createDate", false);
> query.setRefreshingObjects(true);
> setNotifications(((Visit)
> getVisit()).getDataContext().performQuery(query));
>
> For what it's worth, the DataContext is always pulled out of a Tapestry
> session/visit object. Everything pretty much works except when you try
> to delete a notification (actually, the PSEnumeratedItem that was
> inserted into the join table) immediately after inserting it. It throws
> an exception before it tries to delete (issue SQL) the PSEnumeratedItem.
> For some reason, it is trying to construct the update clause for an
> FENotification and the snapshot is null (or something like that -- I can
> produce a stack trace if desired).
>
> Delete code:
>
> notification.removeFromItems(item); // remove the PSEnumeratedItem in
> the join table
> dataContext.deleteObject(item);
> dataContext.commitChanges();
>
> The above code works on everything except a PSEnumeratedItem that was
> *just* inserted, unless the reset is called twice. Kind of whacky. :-)
>
> Thanks!
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andru..bjectstyle.org]
> Sent: Wednesday, December 15, 2004 9:22 AM
> To: cayenne-use..bjectstyle.org
> Subject: Re: Delete after insert?
>
>
> Michael,
>
> I am not aware of this problem. If you can reproduce this consistently,
> could you possibly create a test case and submit a bug report?
>
> Andrus
>
>
>> Does anyone know of any issues (Cayenne 1.1) with deleting a row
>> immediately after inserting it?
>>
>> In a nutshell, if I do:
>>
>> Insert, sets (relationships only), commit, reset (a method which
>> refetches the detail page data), delete (same object just inserted),
>> commit, it dies while trying to figure out the update clause on
>> something I didn't change.
>>
>> However, this sequence seems to work:
>>
>> Insert, sets (relationships only), commit, reset, reset (again),
> delete
>> (same object just inserted), commit, it works. It's just slower
> because
>> the reset does a fetch, so it is doubly-fetched.
>>
>> Thanks,
>>
>> /dev/mrg
This archive was generated by hypermail 2.0.0 : Wed Dec 15 2004 - 10:23:45 EST