SQLAlchemy 0.9.6 Released
Hey folks - Building on the great success of 0.9.5 just a few hours ago today, 0.9.6 is out! One of the changes in 0.9.5 had more of an impact than expected and I determined it was better just reverting this particular change, as there's a much better solution to it on deck for version 1.0 - this change involved whether or not the None value implicitly created when you do an attribute get should impact the flush process, and it was driven by the edge case of the so-called row switch scenario when an INSERT/DELETE pair is turned into an UPDATE. In 1.0, at the moment it looks like the approach will be to do away with the implicit set of None when you fetch a missing attribute; you'll still get the None but the underlying state won't be changed. For details see issue #3060 and #3061. Download SQLAlchemy 0.9.6 at: http://www.sqlalchemy.org/download.html -- You received this message because you are subscribed to the Google Groups sqlalchemy-alembic group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Could not locate column in row for column
Hello, Mike thank you for your answer for now it works fine with the patch create_engine( description_encoding = 'utf8') 2014-06-20 22:36 GMT+04:00 Mike Bayer mike...@zzzcomputing.com: On 6/20/14, 12:14 PM, Mike Bayer wrote: On 6/20/14, 7:32 AM, Mike Bayer wrote: NoSuchColumnError: Could not locate column in row for column '\\u0417\\u0430\\u043a\\u0430\\u0437\\u044b.\\u041d\\u043e\\u043c\\u0435\\u0440 \\u0437\\u0430\\u043a\\u0430\\u0437\\u0430' The problem is i can't really debug this error because it isn't clear what should be in pk_cols Previously in orm/loading.py there is a string pk_cols = mapper.primary_key # line number 250 So, pk_cols is a list of Column() objects. row is a list of values from query Surely, [row[column] for column in pk_cols] raises error, because column is a Column() object and can't be index for row. But i can't imagine how this code may work. Is this a bug? the ResultProxy contains translation logic that receives Column objects and locates the data by name. This is documented at http://docs.sqlalchemy.org/en/rel_0_9/core/tutorial.html#selecting and is the primary method by which the ORM relates mapped columns to result sets. In this case the issue is most likely yet another pyodbc + unicode encoding issue, of which there are many, and often there's no way to work around. Need to know 1. OS platform 2. FreeTDS version 3. UnixODBC or iODBC (and what version) 4. pyodbc version 5. SQL Server version. I can try to test but often these unicode issues aren't easy to resolve (have you tried pymssql? ).thanks. good news, I can reproduce this, and on my end at least it needs the so-called description_encoding workaround. We may have to revisit the defaults on this parameter for modern versions of Pyodbc. The test below produces your error without the param, resolves with it. Please try this out on your create_engine(), thanks. #! coding: utf-8 from sqlalchemy import * engine = create_engine(mssql+pyodbc://scott:tiger@ms_2008, echo=True, description_encoding='utf8') colname = u'Заказ.Номер заказа' m = MetaData() t = Table(uЗаказы, m, Column(colname, String(30), key='somecol')) m.drop_all(engine) m.create_all(engine) engine.execute(t.insert().values(somecol='some value')) result = engine.execute(t.select().where(t.c.somecol == 'some value')) row = result.fetchone() print row[t.c.somecol] yeah this is the workaround for now, but totally this is a bug back to 0.8 and further, should be backported for 0.8, 0.9 and 1.0 in https://bitbucket.org/zzzeek/sqlalchemy/issue/3091/update-description_encoding-for-pyodbc . Two different issues located. -- You received this message because you are subscribed to a topic in the Google Groups sqlalchemy group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy/svIe6UWMWyU/unsubscribe. To unsubscribe from this group and all its topics, 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. -- Счастливой радости! Тимур Ожегин -- 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.
Re: [sqlalchemy] A question regarding hybrid properties, relationships and schema changes
On Fri, Jun 20, 2014 at 3:46 PM, Ken Lareau klar...@tagged.com wrote:
On Fri, Jun 20, 2014 at 1:23 PM, Mike Bayer mike...@zzzcomputing.com
wrote:
On 6/20/14, 3:38 PM, Ken Lareau wrote:
So in the ongoing improvement of one of our internal databases, we
created
a new table named 'environments' whose SQLA code looks something like
this:
class Environment(Base):
__tablename__ = 'environments'
id = Column(u'environmentID', INTEGER(), primary_key=True)
environment = Column(String(length=15), nullable=False, unique=True)
env = Column(String(length=12), nullable=False, unique=True)
domain = Column(String(length=32), nullable=False, unique=True)
prefix = Column(String(length=1), nullable=False)
Two of our tables recently needed conversion to stop using their own
local
'environment' column to using this table. The first part's been put in
place
(a new foreign key for 'environment_id'), but to prevent large swaths
of code
from needing changes, a thought of using a hybrid property might allow
the
change to be hidden (until the code using it had been rewritten at
least).
My naive attempt was the following (just the relevant snippet):
environment_obj = relationship('Environment')
@hybrid_property
def environment(self):
return self.environment_obj.environment
Unfortunately (and in hindsight for obvious reasons), this code doesn't
work,
what does doesn't work mean here? This will work at the instance
level. At the query level, not so much, that's true, if you truly want no
code to change you'd need to implement an @expression here that's a little
inefficient, as it needs to do a correlated subq:
Yes, the doesn't work was specifically related to an attempt to use it in
a query, which of course failed miserably. :)
class HasEnv(Base):
__tablename__ = 'has_env'
id = Column(INTEGER, primary_key=True)
environment_id = Column(ForeignKey('environments.environmentID'))
environment_obj = relationship('Environment')
@hybrid_property
def environment(self):
return self.environment_obj.environment
@environment.expression
def environment(cls):
return select([Environment.environment]).\
where(Environment.id ==
cls.environment_id).correlate(cls).\
as_scalar()
s = Session()
print s.query(HasEnv).filter(HasEnv.environment == 'some env')
output:
SELECT has_env.id AS has_env_id, has_env.environment_id AS
has_env_environment_id
FROM has_env
WHERE (SELECT environments.environment
FROM environments
WHERE environments.environmentID = has_env.environment_id) = :param_1
wont perform well from a SQL perspective but will do the job...
This worked perfectly, thank you! This is honestly a stop-gap measure
to allow much of the code to be rewritten (after which it can be removed),
and for what it's being used for at the moment, it won't be too bad
regarding
performance.
but a very brief conversation with someone on the #sqlalchemy channel
on
Freenode indicated there was no way to do this and all the relevant code
must be reworked. While it's only a few dozen places this occurs, I can
see
this coming up again in the future as further schema refactorings occur,
so
I turn to those with more expertise to find out if there is a way to
accomplish
what I desire, or if there's really no hope. :) Any insight would be
greatly
appreciated.
I don't know how to fix this issue with IRC and stackoverflow that people
constantly are getting bad information.
Heh, Sometimes I think I should know better about asking for help
on IRC, but sometimes I get lucky. In this case, I decided I might
have better luck on the mailing list after the answer I got on IRC
was very unsatisfactory. :)
Thanks for the help!
D'oh, seems like I spoke too soon; there's a specific instance where
this fails due to some subquery stuff I'm doing:
if apptier:
subq = (
Session.query(
Package.pkg_name,
Package.version,
Package.revision,
AppDefinition.app_type,
AppDeployment.environment
).join(Deployment)
.join(AppDeployment)
.join(AppDefinition)
.filter(Package.pkg_name == package_name)
.filter(AppDeployment.environment == env)
.filter(AppDeployment.status != 'invalidated'))
[...]
# The actual column name must be used in the subquery
# usage below; DB itself should be corrected
versions = (Session.query(subq.c.appType,
subq.c.version,
subq.c.revision)
.group_by(subq.c.appType, subq.c.environment)
.all())
The parts in the subquery work fine, but the access of the 'column'
in the final query leads to this:
Traceback (most recent call last):
