On Mon, Mar 10, 2014 at 12:12 PM, Boris Pavlovic 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.
++
>
> Probably we should so
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 M
On Mon, Mar 10, 2014 at 7: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 :
>>>
>>>
>>> > 3. This would make the instances and shadow_instances tabl
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 :
> 3. This would make the instances and shadow_instances tables
have
> different schem
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 :
> 3. This would make the instances and shadow_instances tables
have
> different schemas, i.e. instances.uuid would be
nulla
On 3/9/2014 9:05 PM, ChangBo Guo wrote:
2014-03-10 4:47 GMT+08:00 Jay Pipes 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 nullable=True in
On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote:
>
>
>
> 2014-03-10 4:47 GMT+08:00 Jay Pipes :
>
>
> > 3. This would make the instances and shadow_instances tables
> have
> > different schemas, i.e. instances.uuid would be
> nullable=False i
2014-03-10 4:47 GMT+08:00 Jay Pipes :
>
>
> > 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 this matte
Hi Matt, interesting questions/points. Some comments inline.
On Sun, 2014-03-09 at 15:20 -0500, Matt Riedemann wrote:
>
> 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 migrati
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
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 defines
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
+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 UUID
I've got a blueprint [1] scheduled for icehouse-3 to add DB2 support to
Nova. That's blocked by a patch working it's way through
sqlalchemy-migrate to add DB2 support [2] there.
I've held off pushing any nova patches up until the sqlalchemy-migrate
DB2 support is merged (which is also blocked
14 matches
Mail list logo
