Hey Kevin, 704 session.execute('update instances set deleted=1,' 705 'deleted_at=:at where id=:id', 706 {'id': instance_id, 707 'at': datetime.datetime.utcnow()})
In this case, it isn't desirable to modify updated_at. We don't ever destroy actual rows from mysql for a number of reasons (auditing, performance, etc). We simply flagged them as deleted=1 and filter those rows out later. So in this case it only makes sense to update deleted_at and not updated_at, since, abstractly speaking, this is not an update operation. Best, Devin On Mar 9, 2011, at 11:22 AM, Kevin L. Mitchell wrote: > Howdy; I'm looking into bug 722979 (convert calls to > session.execute("update <blah>") to SQLAlchemy code), and I noticed that > using session.execute() in places like > trunk/nova/db/sqlalchemy/api.py:704 has the effect of NOT updating the > 'updated_at' column inherited from models.NovaBase; this would contrast > with the naive approach to changing this to use SQLAlchemy calls, which > would cause 'updated_at' to be updated. > > My question is, is there any reason 'updated_at' should NOT be updated? > I can't imagine there's a problem with it, but I'm still just getting > started, and so I thought I'd check. > > Thanks! > -- > Kevin L. Mitchell <kevin.mitch...@rackspace.com> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp