Open Stack

Hi Jay,


When I started working around unique keys, I tried to use deleted_at
column. so answer about why we don't use deleted_at column you could read
in Devananda's comment on my patch https://review.openstack.org/#/c/16162/ .

Also I should mention that this is really huge change and it will take a
lot of time to implement it.  E.g. I started working around unique keys at
begin of the Grizzly and we still didn't finish this work in OpenStack
projects (except Nova where we have last the patch on review
https://review.openstack.org/#/c/36880/).


Best regards,
Boris Pavlovic
--
Mirantis Inc.







On Mon, Aug 19, 2013 at 11:39 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> I'm throwing this up here to get some feedback on something that's always
> bugged me about the model base used in many of the projects.
>
> There's a mixin class that looks like so:
>
> class SoftDeleteMixin(object):
>     deleted_at = Column(DateTime)
>     deleted = Column(Integer, default=0)
>
>     def soft_delete(self, session=None):
>         """Mark this object as deleted."""
>         self.deleted = self.id
>         self.deleted_at = timeutils.utcnow()
>         self.save(session=session)
>
> Once mixed in to a concrete model class, the primary join is typically
> modified to include the deleted column, like so:
>
> class ComputeNode(BASE, NovaBase):
>     <snip>...
>     service = relationship(Service,
>                            backref=backref('compute_node'**),
>                            foreign_keys=service_id,
>                            primaryjoin='and_('
>                                 'ComputeNode.service_id == Service.id,'
>                                 'ComputeNode.deleted == 0)')
>
> My proposal is to get rid of the deleted column in the SoftDeleteMixin
> class entirely, as it is redundant with the deleted_at column. Instead of
> doing a join condition on deleted == 0, one would instead just do the join
> condition on deleted_at is None, which translates to the SQL: AND
> deleted_at IS NULL.
>
> There isn't much of a performance benefit -- you're only reducing the row
> size by 4 bytes. But, you'd remove the redundant data from all the tables,
> which would make the normal form freaks like myself happy ;)
>
> Thoughts?
>
> -jay
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/a01c67be/attachment.html>