[odb-users] Best Practice deleting persistent objects

[David Hinson]

At the risk of pushing the discussion beyond ODB support, another alternative would be to separate the concern of relationship ownership away from both the user and group classes into its own class that represents a relationship and is persisted directly.  You could then make a relationship manager object that serves as both factory and lookup for those relationships.  That would allow you to easily decouple relationship policies away from the principal objects which might be important if the relationships grow in complexity.  For instance, if you were to start applying non-trivial criteria for group membership that pulled in other data model elements then it might become very undesirable to couple their implementations to either the user or group implementations.  Of course that would be more of an enterprise level solution.  If you're making something simpler like a device level ACL then you may not be able to justify those extra components.


-----Original Message-----
From: odb-users-bounces at codesynthesis.com [mailto:odb-users-bounces at codesynthesis.com] On Behalf Of Steven Côté
Sent: Thursday, April 03, 2014 11:26 AM
To: ODB Users Mailing List
Subject: Re: [odb-users] Best Practice deleting persistent objects

>
> 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.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3462 / Virus Database: 3722/7292 - Release Date: 04/03/14