[sqlalchemy] Re: Why does SA (only 0.6.x) read data from n:m relationships when updating the parent table?
Hi Michael, I've just installed this package, and it works fine for me. Thanks for fixing the problem. Ciao ciao Ralph On Jul 7, 6:37 pm, Michael Bayer mike...@zzzcomputing.com wrote: can you try out the latest hg tip for me please, I still feel like releasing this today: http://hg.sqlalchemy.org/sqlalchemy/archive/default.tar.gz On Jul 7, 2010, at 10:49 AM, Ralph Heinkel wrote: oh, I'm sorry, but better now than later ;-) Strange that nobody got hit by that bug (or the side effects were not as tremendous as in my case and so they were silently going through with no harm ...) Thanks anyway for looking at this and fixing the problem. Ciao ciao Ralph On Jul 7, 4:08 pm, Michael Bayer mike...@zzzcomputing.com wrote: I so desperately wished you had reported this yesterday before I released. It's an extra load that forgot to get factored out. I may very well release 0.6.3 today as I consider this a very severe issue. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. 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 sqlalch...@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] Re: Why does SA (only 0.6.x) read data from n:m relationships when updating the parent table?
I just noticed this behavior as well, and confirm that the tar.gz that was posted fixed the problem, and doesn't introduce any problems either. On 07/09/2010 05:20 AM, Ralph Heinkel wrote: Hi Michael, I've just installed this package, and it works fine for me. Thanks for fixing the problem. Ciao ciao Ralph On Jul 7, 6:37 pm, Michael Bayermike...@zzzcomputing.com wrote: can you try out the latest hg tip for me please, I still feel like releasing this today: http://hg.sqlalchemy.org/sqlalchemy/archive/default.tar.gz On Jul 7, 2010, at 10:49 AM, Ralph Heinkel wrote: oh, I'm sorry, but better now than later ;-) Strange that nobody got hit by that bug (or the side effects were not as tremendous as in my case and so they were silently going through with no harm ...) Thanks anyway for looking at this and fixing the problem. Ciao ciao Ralph On Jul 7, 4:08 pm, Michael Bayermike...@zzzcomputing.com wrote: I so desperately wished you had reported this yesterday before I released. It's an extra load that forgot to get factored out. I may very well release 0.6.3 today as I consider this a very severe issue. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/sqlalchemy?hl=en. -- David Gardner Pipeline Tools Programmer Jim Henson Creature Shop dgard...@creatureshop.com -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
[sqlalchemy] documentation correction on declarative mixin
http://www.sqlalchemy.org/docs/reference/ext/declarative.html#controlling-table-inheritance-with-mixins In the second example, Engineer has __tablename__ = None But, I think the point of that section, is that it wouldn't be needed. __tablename__ in Tablename should assign None anyway, shouldn't it? laggo on IRC confirmed and said I should post to the mailing list. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
[sqlalchemy] auto create slug - sessionextension?
hello, I'm trying to auto-fill a slug column based on title after creation. Since the slug column is unique i need to check other records to avoid duplication. I've tried a couple of things with sessionextension but with no avail. Has anyone done smth similar? Any ideas or directions? Thanks a lot! -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
[sqlalchemy] Re: alchemy-migrate with DeclarativeBase
On Jun 17, 4:00 am, Francisco Souza franci...@franciscosouza.net wrote: But do I do this? Part of the problem is that I don't know of a way to generate tables other than create_all() (or drop_all()) when using declarative syntax. Is there another way? Hi Shane :) When you bind your declarative base to a metadata, the metadata object has a attribute called tables, wich is a dict with all tables containeds in this metadata. So, you can do a create for a single table easily. Base.metadata.tables['test_case'].create(engine) You can call it on your upgrade function inside the migration module. Isn't this incredibly problematic if you need to change the model definition later? What if you need to add a column to this table in a new migration later on? It will work on your existing databases, but if you run through your migrations on a fresh database, you'll have a problem because the first migration created the table with the extra column in place, and the second migration won't be able to add the column again. The sqlalchemy-migrate docs suggest you copy and paste Table definitions to avoid this behavior (ugh). But when you're using DeclarativeBase you don't even have any Table definitions to copy from! Is there any way around this other than not running migrations when creating new databases (and instead sticking with create_all() directly)? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] documentation correction on declarative mixin
On Jul 9, 2010, at 4:32 PM, Randy Syring wrote: http://www.sqlalchemy.org/docs/reference/ext/declarative.html#controlling-table-inheritance-with-mixins In the second example, Engineer has __tablename__ = None But, I think the point of that section, is that it wouldn't be needed. __tablename__ in Tablename should assign None anyway, shouldn't it? sure the second two examples probably shouldn't have the __tablename__ on Engineer. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
