If your database is transactional, you're just plain wrong. Even
without a transactional database, Cayenne should really do its best to
preserve your operations.
And, I'm still entirely unconvinced that validateForDelete won't do
exactly what you need. Give it a shot first.
On 9/16/05, Gili <cowwo..bs.darktech.org> wrote:
>
> That's not enough. Depending upon the order in which deletes are
> carried out you might still might get a bogus failure. Also, I don't
> think it will work for the following case:
>
> A -> B -> C
> user deletes A
>
> validateForDelete() sees A as deleted but not B because it hasn't been
> deleted yet (by cascade).
>
> Take a look at the example I posted on cayenne-devel for the more
> complex use-case.
>
> Gili
>
> Cris Daniluk wrote:
> > Okay... now I'm with you :)
> >
> > It seems to me that your logic is actually not quite right, because as
> > I see it, an image_data just plain can't be deleted. When WOULDN'T it
> > have a image object? Instead, maybe override validateForDelete for
> > ImageData, and only permit the delete if the object referenced by
> > toImage is already in persistenceStatus DELETED?
> >
> > In other words, I think overriding validateForDelete is the more
> > "Cayenne" approach.
> >
> > Cris
> >
> >
> >
> > On 9/16/05, Gili <cowwo..bs.darktech.org> wrote:
> >
> >> 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/
> >>
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Fri Sep 16 2005 - 15:35:23 EDT