Indexes should be copied by tometadata() and we have test coverage for that (make sure you're on 0.6.5, that's when it was added) so if you can illustrate a failing test we can add another bug report for that.
On Dec 16, 2010, at 4:30 AM, Mr.Rech wrote: > Hi Michael, > thanks for you answer and for the patch. In the meanwhile I > implemented the iteration-through-constraints solution as you > suggested. However I've noticed that the indexes defined for each > table must be copied manually (even when using .tometadata() method). > Is there any better (more obvious way) to copy them from one schema to > another that I can't see by myself? > > Thanks, > Andrea > > On Dec 14, 4:46 pm, Michael Bayer <[email protected]> wrote: >> On Dec 14, 2010, at 3:58 AM, Mr.Rech wrote: >> >> >> >>> Hi everybody, >>> yesterday I was try to copy a table via SA when I noticed a strange >>> behaviour that I think is a bug. >> >>> Here it is a summary of my issue: what I'm trying to do is to copy a >>> list of tables from one schema to another (my backend is Postgresql, >>> but it only marginally matters), and from the docs seems that >>> table_obj.tometadata(meta, schema='new_schema') is the way to go. >> >>> However running my code I got an unexpected error complaining about >>> some unneeded constraints. It turned out one of my tables has a >>> boolean column, and when copying it the CheckConstraint() on it is >>> passed down to the DLL even if Postgresql supports boolean type >>> natively. >> >>> Reading the SA source code for .tometadata() method I noticed that it >>> calls the CheckConstraint.copy() method and the latter doesn't respect >>> self._create_rule attribute when returning a copy of the constraint >>> itself. I think this is a bug, but maybe I'm wrong. I've also searched >>> the bug reports but without success. Can anyone conferm this? As a >>> temporary fix is there any other way to copy tables from one schema to >>> another? >> >> The _create_rule is backend-agnostic and should be copied along with a >> Constraint, so if that fixes the issue then its pretty likely that's your >> bug. The most effort free workaround for the moment would be to use >> create_constraint=False on your Boolean type. If you're looking for more >> effort then you'd iterate through table.constraints to find the >> CheckConstraint, copy the _create_rule over to the other one. >> >> And I'd like to congratulate you on achieving a special day in SQLAlchemy >> history, ticket # 2000 ! which has been added for this issue. It also >> includes a patch that fixes the bug if you want to just patch for now. >> http://www.sqlalchemy.org/trac/ticket/2000 >> >> >> >>> Thanks, >>> Andrea >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sqlalchemy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
