Thanks, I was not aware of the parallel versions. We will try the latest
0.9.
And I do agree that it should never have worked in the first place, it's
just that the client's code base is full of that and it would be hard to
try to remove them all at once.
Thanks for the fast reply, very appreciated.
Antoine
On Friday, May 15, 2015 at 11:21:17 AM UTC-4, Michael Bayer wrote:
>
>
>
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
