[odb-users] Best Practice deleting persistent objects

Per Edin info at peredin.com
Thu Apr 3 11:43:02 EDT 2014


I would advice against ON DELETE CASCADE in this particular case
though. 1. It can lead to real headaches if someone removes a group by
mistake, either by removing a group from within C++ code or by an
accidental DELETE FROM group WHERE... the cascade doesn't give any
warnings at all. 2. Removing a group doesn't necessarily mean the
users shall be removed, since a user can be in 0 groups or already is
a member of other groups.

I think the best solution would be to have a list of users in the
group and an inverse list of groups in the user. This seems to be the
most logical approach since a group contains users instead of users
pointing to their parents. Instead of relying on ON DELETE CASCADE you
could implement void detach_all_users() in the group class which very
clearly states what it does.

On Thu, Apr 3, 2014 at 5:26 PM, Steven Côté <steven.cote at gmail.com> wrote:
>> Solution 0 limits the number of groups a user can be in to at most 1.
>>
>> Perhaps the first issue is to determine if a user shall be able to be
>> in 1 or more groups? :)
>
>
> It is true. In this particular case, a user can be in 0 to * groups. So
> option 0 as written won't work for me. Judging by the rest of the answers,
> it sounds like the real answer is to link the group back to the user. So in
> my case it would be something like:
>
> class group;
>
> #pragma db object
> class user
> {
>    ...
>
>    std::vector<group*> belongs;
> };
>
> #pragma db object
> class group
> {
>      ...
>
>      #pragma db inverse(belongs)
>      std::vector<user*> member;
> };
>
> Is it possible to describe a relationship like that in the pragma language?
> I'll have a flip through the manual in the morning to see if there's any
> mention of that. Otherwise I guess I'm waiting for version 2.4.0.



More information about the odb-users mailing list