>> I don't think it's all that ambitious to think we can just use >> tried and tested schema evolution techniques that work for everyone >> else. > > People have been asking me for over a year how to do this, and I have > no easy answer, I'm glad that you do. I would like to see some > examples of these techniques.
I'm not sure how to point you at the examples we have today because they're not on a single line (or set of lines) in a single file. Nova has moved a lot of data around at runtime using this approach in the last year or so with good success. > If you can show me the SQL access code that deals with the above > change, that would help a lot. We can't show you that, because as you said, there isn't a way to do it...in SQL. That is in fact the point though: don't do it in SQL. > If the answer is, "oh well just don't do a schema change like that", > then we're basically saying we aren't really changing our schemas > anymore except for totally new features that otherwise aren't > accessed by the older version of the code. We _are_ saying "don't change schema like that", but it's not a very limiting requirement. It means you can't move things in a schema migration, but that's all. Nova changes schema all the time. In the last year or so, off the top of my head, nova has: 1. Moved instance flavors from row=value metadata storage to a JSON blob in another table 2. Moved core flavors, aggregates, keypairs and other structures from the cell database to the api database 3. Added uuid to aggregates 4. Added a parent_addr linkage in PCI device ...all online. Those are just the ones I have in my head that have required actual data migrations. We've had dozens of schema changes that enable new features that are all just new data and don't require any of this. > That's fine. It's not what people coming to me are saying, though. Not sure who is coming to you or what they're saying, but.. okay :) If keystone really wants to use triggers to do this, then that's fine. But I think the overwhelming response from this thread (which is asking people's opinions on the matter) seems to be that they're an unnecessary complication that will impede people debugging and working on that part of the code base. We have such impediments elsewhere, but I think we generally try to avoid doing one thing a hundred different ways to keep the playing field as level as possible. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
