Here's another patch which switches the behavior of row.keys(), then adds a test where a special exception needs to be made for SQLite. This would have keys come right back as they are. This would break the behavior of keys() in the other direction, for those who might be using UNION with table-qualified column names (as the ORM always does).
Perhaps you can use another accessor raw_keys() ? what is the use case here
for dots in label names + keys() ?
On Apr 27, 2012, at 9:55 AM, Michael Bayer wrote:
> this is an issue of two edge cases.
>
> One edge case is you want to emit this SQL on SQLite:
>
> select query_users.user_id, query_users.user_name from query_users
> UNION select query_users.user_id, query_users.user_name from query_users
>
> and then access the columns like this:
>
> row["user_id"], row["user_name"]
>
> which is of course how every other database does it. Only SQLite decides
> that only when a UNION is present, it's going to prepend the tablename to the
> keys in cursor.description. So we strip them off so that the ORM and
> everything else still works when a query like this comes through.
>
> The other edge case is you want to explicitly use a label with a dot in it.
>
> As it stands, we can choose among these two edge cases, and I'd note in the
> current behavior, you *can* access your column using "foo.bar", it's just not
> in keys() that way. In my view, being able to emit a UNION with
> table-qualified columns is a lot more common than labels with dots in them.
> Why not use another character that isn't meaningful in SQL ?
>
> A patch to disable the behavior is below. If you can get
> test.sql.test_query, which tests the above UNION case, to pass in some other
> way with SQLite, that fix will go right in.
>
> diff -r 813168d05065 lib/sqlalchemy/dialects/sqlite/base.py
> --- a/lib/sqlalchemy/dialects/sqlite/base.py Thu Apr 26 11:59:50 2012 -0400
> +++ b/lib/sqlalchemy/dialects/sqlite/base.py Fri Apr 27 09:50:48 2012 -0400
> @@ -572,7 +572,7 @@
> # in the case of UNION may store col names as
> # "tablename.colname"
> # in cursor.description
> - if "." in colname:
> + if False: #"." in colname:
> return colname.split(".")[1], colname
> else:
> return colname, None
>
>
>
>
> On Apr 27, 2012, at 2:24 AM, Stefan Urbanek wrote:
>
>> Hi,
>>
>> I had this problem ~year ago (see [1]). Now with SQLAlchemy 0.7.6 I am
>> having this same problem back again. Here is a piece of code that shows this
>> behaviour, in comparison to other backends as well:
>>
>> https://gist.github.com/2506388
>>
>> Verbosity and non-reusing instances is intentional.
>>
>> Is there any workaround for this issue?
>>
>> Thanks for any hints,
>>
>> Stefan
>>
>> [1] http://bit.ly/Je8V4I Selecting columns with dots in their names
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/sqlalchemy/-/xgqjb8tLAW8J.
>> 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.
-- 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.
On Apr 27, 2012, at 9:55 AM, Michael Bayer wrote:
|
sqlite_keys.patch
Description: Binary data
