On 5/15/15 9:56 AM, Antoine Leclair wrote:
Hi all,
I recently tried to update SQLAlchemy from 0.9.4 to 1.0.4 in a
client's project. However, I run into an error that is not there with
0.9.4.
It happens for this type of query:
q = DBSession.query(User) \
.filter(User.profile_id.in_(profile_ids)) \
.join(Profile)
q = q.outerjoin(
CouplePhoto,
and_(
User.profile_id==CouplePhoto.profile_id,
CouplePhoto.avatar==True
)
)
q = q.with_entities(User.profile_id, User.given_name, User.zipcode,
CouplePhoto.filename, User.gender, Profile.sex)
users_data = q.all()
for u in users_data:
if u.filename:
*# the next line causes the error in 1.0.4*
*u.filename = 'something'*
In 0.9.4, the type of "u" was "KeyedTuple" and in 1.0.4, it's
"result". The error is "AttributeError: can't set attribute".
The goal of this assignation is to recompute the filename according to
the original filename (to show a thumb instead of original). It is not
saved in the database.
Now, I know this is not necessarily good design and I would not have
done it that way myself. But the code base is probably full of this
type of thing, mixed with business logic, and trying to fix them is
clearly not doable in the short term.
let's look at the behavior of Python's own "namedtuple":
>>> import collections
>>> my_tuple = collections.namedtuple('x', ['a', 'b'])
>>> rec = my_tuple(1, 2)
as we can see, assigning to a tuple is not allowed:
>>> rec.a = 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: can't set attribute
additionally, the tuple doesn't allow any other attributes to be set
either; this is actually not working in 1.0.4's version of the tuple but
we just fixed this for 1.0.5:
>>> rec.c = 7
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'x' object has no attribute 'c'
So unfortunately your code is doing something that never should have
been allowed.
And we have to update SQLAlchemy, because some circular reference
issue was fixed when using Alembic somewhere between 0.9.4 and 1.0.4.
SQLAlchemy's releases are parallel, where we support multiple X.Y series
at the same time for a short period. In this case, the 0.9 series is
separate and is in maintenance mode. The reason these parallel releases
exist is exactly so that existing applications can take all the time
they need, in some cases years, to upgrade their applications to the
newer major version (see the bottom of
http://www.sqlalchemy.org/download.html to get a feel for this). So
there is no reason for you to be using the 1.0 series, stay with the 0.9
series (currently at 0.9.9) until you have the opportunity to upgrade
your development tree to the 1.0 series. I'm not familiar with the
bug you refer to but critical Python-level bugs are typically backported
and I'm sure that if this is a documented bug fixed since 0.9.4, it's in
the 0.9 series.
--
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.
For more options, visit https://groups.google.com/d/optout.
