On 04/26/2016 12:11 PM, Piotr Dobrogost wrote:
On Tue, Apr 26, 2016 at 12:18 AM, Mike Bayer <[email protected]> wrote:
On 04/25/2016 11:04 AM, Piotr Dobrogost wrote:
Is caching using dogpile what you call "Query cache extension"? If so
we don't use it.
this extension:
http://docs.sqlalchemy.org/en/rel_1_0/orm/extensions/baked.html?highlight=baked#module-sqlalchemy.ext.baked
Ok. I see this being used in Kotti (the framework I use). For example
here
https://github.com/Kotti/Kotti/blob/0d162332e369dedb1b4936935e43de89e9665f8e/kotti/resources.py#L812
the stack trace shown here illustrates an INSERT statement in the context of
an ORM flush, which does use the compiled_cache feature; so to that degree,
this part of the puzzle makes sense.
I'm curious what in the log shows that we deal with "INSERT statement
in the context of an ORM flush"?
However, in cx_oracle, an INSERT statement does not return rows there's no
data to be returned; cursor.description should be None and the
BufferredColumnResultProxy will not be used. An INSERT statement in
Oracle that uses "RETURNING", as is usually the case for the ORM INSERT
statement, uses OUT parameters to achieve this and will make use of the
ReturningResultProxy to work around what's needed here.
Ok.
Since we're working without a test case of any kind, are you sure that the
result proxy indicating the problem is not a ReturningResultProxy ? Are we
dealing with a column that has a server-generated default value that is of
type BLOB, CLOB, or similar ?
There is ReturningResultProxy in the call stack for example here
https://gist.github.com/piotr-dobrogost/6d57cacb9e77f59748353b2b6c1334d7#file-call-stack-while-executing-line-519-of-result-py-run-for-the-first-time-ever-during-app-startup-L58
and it's the type of "self" which I showed here
https://gist.github.com/piotr-dobrogost/6d57cacb9e77f59748353b2b6c1334d7#file-call-stack-while-executing-line-519-of-result-py-run-for-the-first-time-ever-during-app-startup-L74
It occurred to me that one can reproduce this rather easily installing
Kotti framework alone (or rather slightly modified version adjusted to
work with Oracle which you can find at
https://github.com/piotr-dobrogost/Kotti/tree/sfx).Kotti has
requirements.txt file where you can replace Kotti==1.3.0-alpha.4 with
git+https://github.com/piotr-dobrogost/Kotti.git@sfx and install
everything with `pip install --no-deps -r requirements.txt`. Running
is simple with `pserve development.ini` command (as Kotti is based on
Pyramid). Before running you have to edit development.ini and change
sqlalchemy.url to point to your Oracle db. When run Kotti creates and
populates db and when you try to access app at http://localhost:5000/
the error happens.
Unfortunately I can't accept bug reports of this form. At the level
of, "I can't reproduce it unless I run Kotti", by that logic it is just
as easily a bug in Kotti itself and I don't have the resources to debug
issues in other projects. Kotti developers should be pitching in here
to do the work of extracting the code paths that Kotti is exercising
that produces this otherwise not-yet-reproducible behavior into a
demonstration of unexpected behavior directly against SQLAlchemy.
I'm improving our test suite by ensuring that result processors are
fired off for all result proxy subtypes when caching is used as well and
I will ensure the line of code you mention is exercised. If I can
reproduce your described issue at that level, then the bug will be
located and fixed. I'll keep you posted.
Regards,
Piotr Dobrogost
--
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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
