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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
