That is exactly what I mean.
In my use-case, no one should be allowed to delete an image_data if an
image points to it. However, one should be allowed to delete an image,
which should then delete its associated image_data. See what I mean?
image -> image_data is a to-one relationship.
Gili
Filip Balas wrote:
> I think what Gili is trying to accomplish is a more
> robust mechanism for defining cascading deletes.
>
> As far as I know, what he is describing is not
> supported by Cayenne (and I would be impressed if
> any ORM supported it). What he is describing seems
> to be a way to define and resolve delete dependencies.
>
> What he wants is a way to define a cascade direction
> (already supported by Cayenne)
> i.e.
> delete(grandparent [A]) cascade delete(parent [B]) cascade delete(child [C])
>
> But he also wants to define delete dependencies.
> (As far as I know, not supported by Cayenne)
> So he wants a way to tell cayenne NOT to allow the deletion of
> [C] records that have [A] records related indirectly to them via [B]
>
> I believe this is what he was talking about in his first post,
> then in the second post he described an algorithm for resolving
> nested dependencies so his feature would work.
>
> Correct me if I mis-understood you Gili.
> Correct me if Cayenne supports this somehow [usergroup].
> Sounds like a useful feature (I do this in my business logic right now)
>
> Filip
>
>
> On 9/16/05, Cris Daniluk <cris.danilu..mail.com> wrote:
>
>>Now I'm really confused... what the hell is C? :)
>>
>>Are you using a join table? If so, are you using flattened
>>relationships? Please describe the problem in detail. I think what you
>>want to accomplish is perfectly doable, but its hard to tell with what
>>you've given.
>>
>>On 9/16/05, Gili <cowwo..bs.darktech.org> wrote:
>>
>>> I'm setting DENY in the modeler. What I am trying to communicate to
>>>Cayenne is that it is all right to delete(Master) -- this should trigger
>>>the deletion of all children -- but it is not alright to delete(Child).
>>>
>>> If I have:
>>>
>>>- A -> B -> C (cascading delete)
>>>- C is set to DENY if any instances of A are referencing it
>>>- User deletes A
>>>
>>> then I expect it to work because A is saying "I'll delete my reference
>>>to C if it'll let me delete it" and that should be quite all right.
>>>
>>>Gili
>>>
>>>Cris Daniluk wrote:
>>>
>>>>On 9/15/05, Gili <cowwo..bs.darktech.org> wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>> I've got this relationship:
>>>>>
>>>>>On delete of A, cascade to B
>>>>>On delete of B, if any "A" instances exist, DENY
>>>>>
>>>>> What I'm seeing at runtime is that I delete A, it tries to cascade to B
>>>>>but this fails because A is still associated with it. Cayenne doesn't
>>>>>seem to be smart enough to notice this is ok because A is the one
>>>>>triggering the delete in the first place. Here are the logs I get at
>>>>>runtime (I added these to the code):
>>>>
>>>>
>>>>When you say DENY, are you referring to how you have it set up in the
>>>>Modeler, or in the database? Are you sure you don't mean to have "No
>>>>action"?
>>>>
>>>>If you use a master/child relationship, it sounds like you're doing:
>>>>
>>>>delete(Master) => delete(Children)
>>>>
>>>>delete(Child) => deny
>>>>
>>>>But that doesn't make a whole lot of sense... alternatively, you might be doing:
>>>>
>>>>delete(Child) => delete(Master)
>>>>
>>>>delete(Master) => deny if children
>>>>
>>>>Again, not making a whole lot of sense to me. I am probably not quite
>>>>getting what you're trying to do here, but it sounds like Cayenne is
>>>>doing the right thing. You generally want to pair a cascade and no
>>>>action, not a cascade and deny.
>>>>
>>>>Cris
>>>>
>>>
>>>--
>>>http://www.desktopbeautifier.com/
>>>
>>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Fri Sep 16 2005 - 13:49:07 EDT