Open Stack

On 11/20/2015 10:19 AM, Alexis Lee wrote:
> We just had a fun discussion in IRC about whether foreign keys are evil.
> Initially I thought this was crazy but mordred made some good points. To
> paraphrase, that if you have a scale-out app already it's easier to
> manage integrity in your app than scale-out your persistence layer.
>
> Currently the Nova DB has quite a lot of FKs but not on every relation.
> One example of a missing FK is between Instance.uuid and
> BandwidthUsageCache.uuid.
>
> Should we drive one way or the other, or just put up with mixed-mode?

For the record, I hate the mixed mode.

>
> What should be the policy for new relations?

I prefer consistency, so if we're adding new relationships I'd prefer to 
see that they have foreign keys.

>
> Do the answers to these questions depend on having a sane and
> comprehensive archive/purge system in place?

I'm not sure. The problems this is causing with archive/purge is that I 
thought to fix archive all we had to do was reverse sort the tables, but 
which was working until it turned out we weren't soft deleting 
instance_actions. But now it also turns out that we aren't soft deleting 
bw_usage_cache *and* we don't have a FKey from that back to the 
instances table, so it's just completely orphaned and never archived or 
deleted, thus leaving that task up to the xenserver operator (since the 
xenserver driver is the only one that implements the virt driver API to 
populate this table).

So again, now we have to have special hack code paths in the 
archive/purge code to account for this mixed mode schema.

>
>
> Alexis (lxsli)
>

-- 

Thanks,

Matt Riedemann