Open Stack

On 04/25/2012 05:17 PM, Vishvananda Ishaya wrote:
> The main issue is when the relevant tables are moved into a separate
> service a la quantum or cinder. We can't keep referential integrity
> across multiple databases, so the foreign keys in this case need to be
> removed. It leads to an odd situation when there is still an internal
> implementation in addition to the external implementation because the
> internal implementation no longer has foreign keys.
>
> As an example, we used to have foreign key relationships between
> instances and networks. We can no longer have these because we support
> networks declared externally. The internal network management now has no
> referential integrity, but this is the price we pay for separation of
> concerns. We are going through a similar set of relationship-breaking
> with the volume code.

There are definitely the practical aspects of where this "can't" be done 
because the services have split out, and I think that's fine.

But enforcing the ref constraints where possible just provides another 
level of safety in the data. A policy where we break FK relationships if 
the preferred core model is 2 services (i.e. Nova / Quantum), but we add 
FK constraints within a service might be a good idea.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sldague at us.ibm.com
alt-email: sdague at linux.vnet.ibm.com