so process_revision_directives is a pathway here to the extent that you need to modify the autogenerate process such that a table like this is generated for you automatically.
However, Alembic's normal mode of usage is that the "autogenerate" tool is only a time-saver, and is not intended to produce a finished result in every case. The files it produces contain a comment to this effect that you should "please modify as needed" the migration script that is created. Whether or not you need autogenerate to automate this, the first step would be to come up with the appropriate op.create_table and op.alter_table directives that accomplish what you need, and then manually work these into a migration script as a proof of concept. If this is just one or two tables in your whole application that need to be generated this way, you'd just leave it at that. The "uniqueidentifier" part of this you can get through the sqlalchemy.dialects.mssql.UNIQUEIDENTIFIER datatype. The "ON [PRIMARY]" part I'm not sure if the SQL server dialect supports that syntax right now. If you need that syntax then we'd have to alter SQLAlchemy to support that, unless you were to render the DDL entirely as a string. let me know if that gets you started. On Mon, Mar 19, 2018 at 12:08 PM, marc beirne <marclucbei...@gmail.com> wrote: > From issue here, closed as usage question: > > https://bitbucket.org/zzzeek/alembic/issues/485/mssql-clustered-index-non-primary > > Original question: > > Is there a solution for autogenerating in a single pass MSSQL tables with a > primary key which isn't the clustered index, and a clustered index on a > different column. > > Just defining a second clustered index column creates an exception because > MSSQL is automatically setting the primary key to be the clustered index, > setting index=False on that column definition doesn't help. > > If you manually run two revisions, one without the pks and then add the pks > in later everything is fine but I can't see a way to configure the > autogeneration to push constraint definitions to later statements, which > would work, or force MSSQL not to create the clustered index on the PK. > > > Original Response: > > if you can show me the DDL you want to emit I can help get you there. > > this is a usage question so far so let's pick it up on > https://groups.google.com/forum/#!forum/sqlalchemy-alembic. thanks! > > > > This is an example of the DDL that think someone would need to do this > >> CREATE TABLE [dbo].[test_temp_table]( >> [test_temp_table_clustered_id] [uniqueidentifier] NULL, >> [test_temp_table_id] [int] NOT NULL, >> [test_temp_column] [nvarchar](100) NULL >> ) ON [PRIMARY] >> >> >> CREATE CLUSTERED INDEX [arbitrary_name] ON [dbo].[test_temp_table] >> ( >> [test_temp_table_clustered_id] ASC >> ) >> >> ALTER TABLE test_temp_table >> ADD CONSTRAINT pk_test_temp_table >> PRIMARY KEY (test_temp_table_id) > > > The point is that instead of the primary key being declared inline in the > table definition, it needs to be added after the clustered index is created > because otherwise MSSQL will automatically add a clustered index on the pk > column.. > > Looking at the documentation, I'd think this might be possible through > > "process_revision_directives" > > But when I try and use this to split out the table generation and primary > key addition, I need to add to the UpgrtadeOps.ops list: > ops.CreatePrimaryKeyOp(*stuff) > > if I do this, the generation fails later at > alembic.autogenerate.render._render_primary_key > with a NotImplemented written there. > > I don't really understand how this project fits together so I'm not sure > whether that is really something that's not implemented or just a crossed > wire, or how to hack it either way. > > Best Regards, > > Marc > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy-alembic" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy-alembic+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sqlalchemy-alembic" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
