I'm looking through the code, and it looks like deleteObjects() might
allow you to delete another instance of the same object (matching
ObjectId) from a different context than it's registered in.
However, that seems like an unplanned "feature" rather than an
intended operation.
Is there any reason why we'd allow end-user code to do something like this?
We don't have any other methods that allow you to manipulate one
context with an object registered in another.
I'd say we should throw an exception.
Gili, one thing you can do in the future that will make the issue
irrelevent is to always use
themeDataObject.getDataContext().deleteObject(themeDataObject).
Obviously, this only works if you're deleting one object at a time,
but deleteObjects just iterates over a collection and calls
deleteObject anyway.
On 9/8/05, Gili <cowwo..bs.darktech.org> wrote:
>
> Doh :) This was caused by the fact that "context" was not the same as
> "themeDataObject.getDataContext()". Is it possible to add a check inside
> of DataContext.deleteObjects() for this condition and throw an
> exception? Or are there legitimate reasons for allowing this kind of call?
>
> Thank you,
> Gili
>
> Gili wrote:
> > Hi,
> >
> > I have:
> >
> > context.deleteObjects(themeDataObject);
> > context.commitChanges();
> >
> > and with full logging I can see that commitChanges() invokes the
> > following:
> >
> > 19:11:19,390 INFO QueryLogger:421 - --- will run 1 query.
> > 19:11:19,421 INFO QueryLogger:377 - --- transaction started.
> > 19:11:19,453 INFO QueryLogger:315 - SELECT t0.clazz, t0.dataDigest,
> > t0.id, t0.contentType, t0.data, t0.provider, t0.specification, t0.theme
> > FROM image t0 WHERE t0.theme = ? [bind: 200] - prepared in 16 ms.
> > 19:11:19,500 INFO QueryLogger:360 - === returned 0 rows. - took 63 ms.
> > 19:11:19,515 INFO QueryLogger:386 - +++ transaction committed.
> >
> > It does this because I've got it cascade set to DENY if any images
> > are associated with a theme being deleted. I expect that once it sees
> > that the delete is safe it should delete the theme from the DB, but i
> > never does. How do I find out why the theme is not being removed? Is
> > there extra logging I can enable? It looks like it's failing silently.
> > The theme being deleted has a COMMITED persistence state.
> >
> > Thanks,
> > Gili
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 11:14:11 EDT