Re: [GMG-Devel] Federation, table setup, and permissions

[Christopher Allan Webber]

Joar Wandborg writes:

>>     - Options for modeling things
>>
>>       - Different tables: MediaEntry/User vs MediaEntryRemote/UserRemote
>>
>>         Gets around the fact that restrictions are different depending
>>         on whether something is local or not
>>
>>         Adds new restrictions though.
>>
>>       - We could have a single table for things like MediaEntry and
>>         User but have a boolean for "local" (or "remote")
>>
>>         This would be easier to query.  It would mean a messier model
>>         though.  It would also mean that some of our constraints might
>>         not be so easy anymore.
>>
>>     - I'm assuming that the single table thing is the right solution.
>
> I'm leaning towards separate tables. I can't really say why, which makes 
> my opinion merely more useful than useless. I need to figure out things.
>
> - Hopefully SQLAlchemy can help us out with a 'helper' table that really 
> is two separate tables.
> - Separation of the tables gives us some semantical separation since 
> remote and local users will have different rights/action endpoints. I 
> need Jessica to confirm if there is any truth to this.
> - The respective helper could then be named differently from the 
> local/remote tables so that you can easily tell whether you need to 
> logically handle federation or not.
>

I didn't manage to incorporate feedback from last week's discussion on
IRC into here.  While I thought the single-table thing made most sense,
Jessica and Elrond both thought that there should be a single table with
common elements and, depending on whether local or remote, join with a
separate "local" or "remote" specific data.

There's a good point that we can't do totally separate tables, there
will have to be a shared table whether it contains all the data or not.
If you have a comment entry, the foreign key needs to point to a
specific table... whether that's a comment or not.

I'm a bit worried there whether or not there will be serious performance
issues with too many joins.  I've been worried about that ever since
this meeting:

  http://wiki.mediagoblin.org/Subscriptions

Jessica and Elrond do not seem as worried and seem more concerned about
keeping the tables slim and splitting things across tables if that means
avodiding too many useless rows.  I'll admit I don't have a lot of
experience with very large databases in production.

 - Chris