Russ is right, it's still open for changes, though I want to oversee any changes very carefully because I want to make sure we ship something that makes sense overall!
Altering column names is done as part of alter_field (if you look through that huge method, you'll see it somewhere in there); currently, the only override provision on there is to override some ALTER TABLE SQL which isn't going to work in your case. It also doesn't work for SQLite, but there the whole of alter_field is replaced as nothing is doable the normal way. Would you be happy if I could stick a method hook in the middle of alter_field which you can override and then let you put sql_rename_column = None to stop it trying to do that itself? As for dropping defaults, any constraint handling MUST be done with introspection; if you take a look at the introspection backends, there's a beefed-up new API in there as well called get_constraints, which the SchemaEditor's _constraint_names function uses to look up constraints for operations like this. I'd recommend that you implement the new get_constraints API - tell me if you need me to explain it, but I think the PostgreSQL version is pretty readable. Would you still need to hook default creation in this case? Consistent names are not necessary, though obviously preferable for DBAs reading so they don't think Django is mad. If you need to hook default creation/deletion, I can easily add a similar thing into alter_field where if the _sql attribute is set to None we instead call an overrideable method. Andrew On Fri, Dec 20, 2013 at 7:54 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > Trunk is still open for all 1.7 changes; 1.7 alpha is currently planned > for mid January, which is the cutoff point for major API changes; the beta > a month or so after that, which is the final cutoff for minor API changes. > > On top of that - it looks like you're proposing a modification to the > schema migration API - that means you're not proposing a new feature, but > pointing out a bug/limitation in a feature that has been added for 1.7. > That means the window is definitely open, because the original feature is > already there. > > So yes - if you want to propose an API change for 1.7, you've still got > time. > > Yours, > Russ Magee %-) > > On Fri, Dec 20, 2013 at 3:17 PM, Michael Manfre <mman...@gmail.com>wrote: > >> I just started to work on Django 1.7 support for django-mssql and I don't >> remember if it's too far along to get API changes in for the schema editor? >> I've hit a few road blocks with the current implementation of >> BaseSchemaEditor. I've only just started to get up to speed with the new >> changes, so please bear with me. What the API seems to be lacking, at least >> for my needs right now, is more hooks to execute the proper SQL. >> >> There exists an alter_db_table method that acts as a shim for >> sql_rename_table, but such a hook doesn't exist for sql_rename_column. I >> need both of these because MSSQL uses a stored procedure to rename objects >> [1], which needs the table and column names to be strings that haven't >> passed through quote_name(). >> >> The second API issue I've run in to is that MSSQL's equivalent to DROP >> DEFAULT (sql_alter_column_no_default) is to drop a named constraint. To be >> able to do this, I need to be able to define the column's DEFAULT as a >> named constraint (sql_alter_column_default). If the hooked method for these >> were provided with the model and column name, that seems like it would be >> sufficient for me to be able to generate a consistent, unique constraint >> name for both of those. >> >> The above would work when the default constraint was named. If its name >> is not known (e.g. random constraint name for columns created before schema >> migrations), the same hook should be able to allow me to do more invasive >> prodding with MSSQL's schema tables. >> >> [1] sp_rename - http://technet.microsoft.com/en-us/library/ms188351.aspx >> [2] ALTER TABLE - http://msdn.microsoft.com/en-us/library/ms190273.aspx >> >> Regards, >> Michael Manfre >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAGdCwBt3myq%3D9%2BYTtsuJmYOs0S%2BJ6fSQxFxK_Ci6yYDaw%3DR_Gw%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84-q-eMMxOR58Bh2SvGjztdNawcO%3DfsRDvXvikG7ot7iAQ%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uoY%3Dovqme%2BWkUTPX_22GWnA0WxGiyu_yF8sz0mVYQSCiw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
