Mike Kienenberger wrote:
>> 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.
So... why not throw an exception then?
> 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.
I know, but in my code I was not calling deleteObject() individually on
a per-object basis, nor do I want to. Also I believe that deleteObject()
is deprecated.
Sorry lately I've been putting a lot of pressure into making Cayenne
fail-fast on more issues but you said yourself you'd like to improve
Cayenne's error reporting and I feel this is a vital step in the right
direction. Since it makes little sense to apply a context operation on
an object that does not belong to it I don't think anything will be lost
by throwing an exceception. If the design changes in the future we can
simply remove the exception. Anyway, I'd like to add it, are you -1, 0
or +1 on this?
Gili
>
> 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/
>>
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 11:54:46 EDT