[sqlalchemy] Declarative Mapping vs Classic Mapping
My question is regarding sqlalchemy version 0.7.2. Are there any limitations in using declarative or classic mapping while using sqlalchemy? My main concern is there any limitation of declarative mapping which can put me in some situation where I am stuck with the tables it will create? Also what about table schema changes, If I want to add a column or remove a column from table I simply add or remove that attribute in declarative class? I have completed my table design and thinking to create database in one go using declarative mapping. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Declarative Mapping vs Classic Mapping
On Oct 17, 2011, at 1:05 PM, Manav Goel wrote: My question is regarding sqlalchemy version 0.7.2. Are there any limitations in using declarative or classic mapping while using sqlalchemy? there's not, a declarative mapping is nothing more than a small organizing layer on top of the classical system of class + Table + mapper() - all three elements are used in the same way. My main concern is there any limitation of declarative mapping which can put me in some situation where I am stuck with the tables it will create? Declarative allows the full range of table specification that plain Table() allows, and additionally you can use the Table construct directly with any declarative class (I use this style in my current project) as demonstrated at http://www.sqlalchemy.org/docs/orm/extensions/declarative.html#using-a-hybrid-approach-with-table . Also what about table schema changes, If I want to add a column or remove a column from table I simply add or remove that attribute in declarative class? That's a different story. SQLAlchemy's table metadata is only an in-python document describing the structure of an existing schema in a remote database. While table metadata has the ability to emit CREATE statements to this remote database, that's as far as it goes. When using relational databases, adding columns means that an ALTER statement must be emitted on the target database. You'd need to emit these ALTER commands yourself, if you'd like an existing schema to gain new columns that you've added to your SQLalchemy model. Or if you're in development, you can alternatively (and IMHO this is much easier, assuming you're working only with development databases) drop the whole database and recreate it, where the new columns will be present. There is also the approach of using a tool like SQLAlchemy-Migrate which gives you a place to define table alterations, and does the work of composing the ALTER statements in a semi-automated fashion. Regardless, the choice of declarative versus classical has no impact here, save for the fact that SQLAlchemy-Migrate works a little more clearly when you give it Table constructs to work with, rather than copies of your declared classes. When I've used migrate in the past, it's entirely unnecessary to copy the full table definition as its docs suggest, I tend to just use Table(mytable, metadata, autoload=True) to get at the current Table object before applying alterations, so the usage of declarative has no impact. I have completed my table design and thinking to create database in one go using declarative mapping. should be fine it's not that much of a commitment ! -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Declarative Mapping vs Classic Mapping
Thanks for the quick reply. One question here, suppose I add column using Alter Table command and then in class declaration the attribute. Will it see the newly added column then or not? Concern is not issuing ALTER command by hand but is the class can see the newly added column. Regards, Manav Goel On 17-Oct-2011, at 11:06 PM, Michael Bayer wrote: On Oct 17, 2011, at 1:05 PM, Manav Goel wrote: My question is regarding sqlalchemy version 0.7.2. Are there any limitations in using declarative or classic mapping while using sqlalchemy? there's not, a declarative mapping is nothing more than a small organizing layer on top of the classical system of class + Table + mapper() - all three elements are used in the same way. My main concern is there any limitation of declarative mapping which can put me in some situation where I am stuck with the tables it will create? Declarative allows the full range of table specification that plain Table() allows, and additionally you can use the Table construct directly with any declarative class (I use this style in my current project) as demonstrated at http://www.sqlalchemy.org/docs/orm/extensions/declarative.html#using-a-hybrid-approach-with-table . Also what about table schema changes, If I want to add a column or remove a column from table I simply add or remove that attribute in declarative class? That's a different story. SQLAlchemy's table metadata is only an in-python document describing the structure of an existing schema in a remote database. While table metadata has the ability to emit CREATE statements to this remote database, that's as far as it goes. When using relational databases, adding columns means that an ALTER statement must be emitted on the target database. You'd need to emit these ALTER commands yourself, if you'd like an existing schema to gain new columns that you've added to your SQLalchemy model. Or if you're in development, you can alternatively (and IMHO this is much easier, assuming you're working only with development databases) drop the whole database and recreate it, where the new columns will be present. There is also the approach of using a tool like SQLAlchemy-Migrate which gives you a place to define table alterations, and does the work of composing the ALTER statements in a semi-automated fashion. Regardless, the choice of declarative versus classical has no impact here, save for the fact that SQLAlchemy-Migrate works a little more clearly when you give it Table constructs to work with, rather than copies of your declared classes. When I've used migrate in the past, it's entirely unnecessary to copy the full table definition as its docs suggest, I tend to just use Table(mytable, metadata, autoload=True) to get at the current Table object before applying alterations, so the usage of declarative has no impact. I have completed my table design and thinking to create database in one go using declarative mapping. should be fine it's not that much of a commitment ! -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Declarative Mapping vs Classic Mapping
The usual development model encouraged by SQLAlchemy is that class and table definitions are a fixed element of your program, declared at the module level. So typically, adding new columns means you're modifying the source code of your app, then rerunning. That said, if you add a column to a declarative model at runtime, the Declarative metaclass does intercept this and will invoke add_column() on the Table as well as add_property() on the mapper.Existing objects created against the mapper will have undefined behavior regarding this new attribute, however, which again speaks to the practice that an app should really be run with against a fixed schema - the additive modification supported by Table and mapper() still assumes the application is setting itself up when these methods are called, and that the program hasn't already been running for some time. On Oct 17, 2011, at 1:47 PM, Manav Goel wrote: Thanks for the quick reply. One question here, suppose I add column using Alter Table command and then in class declaration the attribute. Will it see the newly added column then or not? Concern is not issuing ALTER command by hand but is the class can see the newly added column. Regards, Manav Goel On 17-Oct-2011, at 11:06 PM, Michael Bayer wrote: On Oct 17, 2011, at 1:05 PM, Manav Goel wrote: My question is regarding sqlalchemy version 0.7.2. Are there any limitations in using declarative or classic mapping while using sqlalchemy? there's not, a declarative mapping is nothing more than a small organizing layer on top of the classical system of class + Table + mapper() - all three elements are used in the same way. My main concern is there any limitation of declarative mapping which can put me in some situation where I am stuck with the tables it will create? Declarative allows the full range of table specification that plain Table() allows, and additionally you can use the Table construct directly with any declarative class (I use this style in my current project) as demonstrated at http://www.sqlalchemy.org/docs/orm/extensions/declarative.html#using-a-hybrid-approach-with-table . Also what about table schema changes, If I want to add a column or remove a column from table I simply add or remove that attribute in declarative class? That's a different story. SQLAlchemy's table metadata is only an in-python document describing the structure of an existing schema in a remote database. While table metadata has the ability to emit CREATE statements to this remote database, that's as far as it goes. When using relational databases, adding columns means that an ALTER statement must be emitted on the target database. You'd need to emit these ALTER commands yourself, if you'd like an existing schema to gain new columns that you've added to your SQLalchemy model. Or if you're in development, you can alternatively (and IMHO this is much easier, assuming you're working only with development databases) drop the whole database and recreate it, where the new columns will be present. There is also the approach of using a tool like SQLAlchemy-Migrate which gives you a place to define table alterations, and does the work of composing the ALTER statements in a semi-automated fashion. Regardless, the choice of declarative versus classical has no impact here, save for the fact that SQLAlchemy-Migrate works a little more clearly when you give it Table constructs to work with, rather than copies of your declared classes. When I've used migrate in the past, it's entirely unnecessary to copy the full table definition as its docs suggest, I tend to just use Table(mytable, metadata, autoload=True) to get at the current Table object before applying alterations, so the usage of declarative has no impact. I have completed my table design and thinking to create database in one go using declarative mapping. should be fine it's not that much of a commitment ! -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to
