On Sep 14, 2011, at 11:22 AM, Justin Levine wrote:
> Howdy --
>
> We're running load tests against our Pylons application, which uses
> SQLAlchemy to hit an Oracle DB. Under load we're getting the following
> errors:
>
> [Tue Sep 13 12:10:45 2011] [error] /opt/wgen-3p/python26/lib/python2.6/
> site-packages/sqlalchemy/orm/mapper.py:2113: SAWarning: Multiple rows
> returned with uselist=False for eagerly-loaded attribute 'entity'
> [Tue Sep 13 12:10:45 2011] [error] populator(state, dict_, row)
> [Tue Sep 13 12:48:46 2011] [error] /opt/wgen-3p/python26/lib/python2.6/
> site-packages/sqlalchemy/orm/mapper.py:2113: SAWarning: Multiple rows
> returned with uselist=False for eagerly-loaded attribute 'entity'
> [Tue Sep 13 12:48:46 2011] [error] populator(state, dict_, row)
> [Tue Sep 13 13:16:49 2011] [error] /opt/wgen-3p/python26/lib/python2.6/
> site-packages/sqlalchemy/orm/mapper.py:2113: SAWarning: Multiple rows
> returned with uselist=False for eagerly-loaded attribute 'entity'
> [Tue Sep 13 13:16:49 2011] [error] populator(state, dict_, row)
>
> As said in the error message, I assume it's returning multiple rows
> for what should be a 1-to-1 relationship, but I'm not sure why this is
> only happening under load. It's happening exclusively with one of our
> entities.
the error means you have a statement like :
select a.*, b.* from a join b on a.id=b.a_id
where uselist=False means that there should be only one row in "b" that has
"a_id" on it. If a second row comes in, that's the warning.
You might want to ensure that the statement being emitted here isn't capable of
returning more than one "b" for each "a", and also that your database has
referential constraints, if possible, which prevent it as well, for example in
the simple case here, "b.a_id" would get a UNIQUE constraint on it so that only
one "b" could belong to an "a" at a time.
Another thing would be to turn these warnings into errors using the Python
warnings filter. Combined with SQL logging, you'd get a full stack trace and
just prior to that the offending SQL statement.
As for why load is the factor here, it's possible that it's not actually a
causative factor, just one which correlates to your app accessing some
particular data that's not in the expected state.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
