On Sep 23, 2013, at 10:04 PM, Ken Lareau <klar...@tagged.com> wrote:
> Hopefully this will make sense... > > I have a database which is in need of some normalization of the column > naming in various tables. In an effort to minimize disruption (since this > is a live database used by many applications), I'm trying to use a two-step > approach: > > 1) Add a new column that will 'mirror' the current primary key column, > then update code to utilize that column once in place > 2) Once all code is converted, remove the original primary key column > and make the new column the primary key instead. > > In an effort to minimize change to the code I have currently using my > SQLAlchemy model, I'm trying to find a way to deal with this from within > the declarative classes themselves. So the questions are: > > - Is this even possible, and if so, how can it be done? > - If not possible, is there a good yet minimally intrusive external > change that can be done? > > My searching through the docs so far hasn't turned up anything useful, > I'm afraid... it depends a lot on how you are generating primary key values. how are the new values being generated? (things like database platform affect this dramatically). if using something like MySQL's autoincrement, you probably want to write a trigger that will populate this new column after an INSERT. overall a trigger is probably the best way to get this extra value in the table efficiently. OTOH if your applications know the new primary key value beforehand, then SQLAlchemy events can be used to copy the value into the new column. you also want to be mindful of indexing on this column, as applications move to use the new column, you probably want queries to still use indexes.
signature.asc
Description: Message signed with OpenPGP using GPGMail
