I agree. I just added this check.
Andrus
On Sep 9, 2005, at 12:08 PM, Mike Kienenberger wrote:
> I'd be for throwing a exception, just as I stated in my original
> message. That'd be a +1 unless there's a specific reason why the
> current behavior is the way it is.
>
> I don't think deleteObject is deprecated, but my most-accessible code
> isn't the most recent. Doesn't make a lot of sense for it to be
> deprecated since deleting a single object is the most common use case
> and is also the most performant (not that iterating over a single item
> collection has much of a performance hit :) )
>
> -Mike
>
> On 9/9/05, Gili <cowwo..bs.darktech.org> wrote:
>
>> 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 - 12:31:43 EDT