[sqlalchemy] Camelot 13.04.13 released
Hello, Camelot 13.04.13 has been released. Camelot provides components to build business applications on top SQLAlchemy and Qt. For screenshots, see : http://www.python-camelot.com/ This release supports SQLAlchemy 0.0.8 and the internals have completely switched from Elixir to Declarative. An overview of the changes can be found here : http://www.python-camelot.com/3/post/2013/04/release-130413.html Cheers, Erik -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] ColanderAlchemy 0.2a1 released!
Fixed. Thank you for the feedback. I also noticed that 0.2a1 release was hidden. I fixed it and it is visible now. Sorry. S. 2013/4/11 Werner werner.bru...@sfr.fr On 12/04/2013 00:01, Stefano Fontanelli wrote: Hi all, ColanderAlchemy 0.2a1 has been released on PyPi. We are waiting feedbacks to add/remove/change features before reach beta version. You can find changelog here: https://github.com/stefanofontanelli/ColanderAlchemy/blob/master/CHANGELOG.txt You can find new doc here: https://colanderalchemy.readthedocs.org/en/latest/ BTW, the colander link on the following page does not work. Werner -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Default table aliasing (or: avoiding conflicts between foo.type_id and foo_type.id)
I ran into an issue today due to the following scenario: table foo (model class Foo) has a column type_id, which refers to the id column of table foo_type (model FooType) session.query(Foo, FooType), since the generated labels alias both foo.type_id and foo_type.id to foo_type_id, and thus the generated SQL duplicates the column labels and causes an exception similar to : InvalidRequestError: Ambiguous column name foo_type.id' in result set! try 'use_labels' option on select statement There's two possible workarounds for this that I can see: 1. Alias one of the tables to something else so there is no conflict (e.g. foo_type to ft. Drawback: This needs to happen in all situations where this might happen 2. Refactor the database in some form such that the resulting column name combinations don't happen. Drawback: Altering the existing db schema may not be feasible. It would be handy, however, to be able to do one of these options instead to avoid the problem from even happening: 1. Set a 'default alias' for a table or column at the mapper/model level. Maybe class FooType can be configured with a default alias of ft, or Foo.id can have a default alias of foo_type_id (which would then make it foo_foo_type_id after applying the table labelling) 2. Set/change the default separator between a table name and a column name when generating column aliases. I could work around this if, as an application-level default, all column labels were table__column (two underscores) instead of table_column. Maybe the separator can be a callable -- (lambda tablename, columnname: tablename + __ + columnname) Is there some other way to solve this that I might be missing? If not, might I humbly submit this as a feature request for an upcoming sqlalchemy version? ;) -- Daniel -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Re: Default table aliasing (or: avoiding conflicts between foo.type_id and foo_type.id)
I don't know how I managed to mangle that and thought I proofread my post, but that second bit should have read: session.query(Foo, FooType) doesn't work, since the label generation aliases both foo.type_id and foo_type.id to foo_type_id and thus causes an exception similar to : ... -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Default table aliasing (or: avoiding conflicts between foo.type_id and foo_type.id)
yeah, I have good news to report on this issue. What you're seeing is not quite a regression from 0.7 to 0.8, it's an error that occurs in 0.8 as it is more strict about ambiguous columns - where in 0.7 the result of the two same-named columns would be that one just gets ignored, in 0.8 it labels both columns as ambiguous. During beta testing, nobody reported this to me, but literally just this week someone posted it on StackOverflow which you can see here: http://stackoverflow.com/questions/15924689/invalidrequesterror-ambiguous-column-name-in-result-set-while-the-reques/15938036 I knew I had seen this issue years ago, and I'm not sure what we did with it then, but clearly more had to be done, so really I just finished it up yesterday here: http://www.sqlalchemy.org/trac/ticket/2702 where I've enhanced the apply_labels functionality of select() to ensure that any dupe labels get pushed out to be totally anonymized - that way the ORM can get to all the column values distinctly and correctly, since it targets the columns in the result using the original Column object (doesn't need to know those names directly). This is a really major issue so I'd like to get 0.8.1 right out the door within a week hopefully. If you download the latest default, the issue should be fixed, and let me know if you can test for me that everything is OK. Additionally, without the benefit of 0.8.1, the immediate workaround is to produce an alias of at least one of the classes: ft_alias = alised(FooType) query(Foo, ft_alias).filter(Foo.id == ft_alias.id)... let me know how it goes. On Apr 12, 2013, at 2:39 PM, Daniel Grace thisgenericn...@gmail.com wrote: I don't know how I managed to mangle that and thought I proofread my post, but that second bit should have read: session.query(Foo, FooType) doesn't work, since the label generation aliases both foo.type_id and foo_type.id to foo_type_id and thus causes an exception similar to : ... -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
