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.
