On 3/9/2014 9:05 PM, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com:
3. This would make the instances and shadow_instances tables have
different schemas, i.e. instances.uuid would be nullable=False in
instances but
On 3/9/2014 9:18 PM, Jay Pipes wrote:
On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com:
3. This would make the instances and shadow_instances tables
have
different schemas, i.e. instances.uuid would
On 03/10/2014 10:11 AM, Matt Riedemann wrote:
On 3/9/2014 9:18 PM, Jay Pipes wrote:
On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com:
3. This would make the instances and shadow_instances tables
have
Joe,
Fully agree. We should just make a blueprint Get rid of soft deletion. So
we will get much better performance of DB + cleaner code, and avoid such
things like shadow tables and DB purge scripts.
Probably we should some other thread to cover this topic?
Best regards,
Boris Pavlovic
On
On Mon, Mar 10, 2014 at 12:12 PM, Boris Pavlovic bpavlo...@mirantis.com wrote:
Joe,
Fully agree. We should just make a blueprint Get rid of soft deletion. So
we will get much better performance of DB + cleaner code, and avoid such
things like shadow tables and DB purge scripts.
++
On 12/16/2013 11:01 AM, Shawn Hartsock wrote:
+1 on a migration to make uuid a non-nullable column. I advocated a few
patches back in Havana that make assumptions based on the UUID being
present and unique per instance. If it gets nulled the VMware drivers
will have have breakage and I have no
Hi Matt, interesting questions/points. Some comments inline.
On Sun, 2014-03-09 at 15:20 -0500, Matt Riedemann wrote:
snip
I've been working on this more and am running up against some issues,
part of this has to do with my lack of sqlalchemy know-how and
inexperience with writing DB
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com:
3. This would make the instances and shadow_instances tables have
different schemas, i.e. instances.uuid would be nullable=False in
instances but nullable=True in shadow_instances. Maybe this doesn't
matter.
No, I don't think
On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com:
3. This would make the instances and shadow_instances tables
have
different schemas, i.e. instances.uuid would be
+1 on a migration to make uuid a non-nullable column. I advocated a few
patches back in Havana that make assumptions based on the UUID being
present and unique per instance. If it gets nulled the VMware drivers will
have have breakage and I have no idea how to avoid that reasonably without
the
On 12/16/2013 11:45 AM, Matt Riedemann wrote:
1. Add a migration to change instances.uuid to non-nullable. Besides the
obvious con of having yet another migration script, this seems the most
straight-forward. The instance object class already defines the uuid
field as non-nullable, so it's
On 12/16/2013 11:59 AM, Russell Bryant wrote:
On 12/16/2013 11:45 AM, Matt Riedemann wrote:
1. Add a migration to change instances.uuid to non-nullable. Besides the
obvious con of having yet another migration script, this seems the most
straight-forward. The instance object class already
12 matches
Mail list logo
