On Mon, Apr 25, 2016 at 3:23 PM, Mike Bayer <mike...@zzzcomputing.com> wrote: > > OK I can try to work with that but that's a very specific feature, you'd > need to be using the Query cache extension,
I have problem finding information on "Query cache extension". Googling for <query cache extension sqlalchemy> I get http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching as the first result from SA's docs and http://stackoverflow.com/questions/204918/does-sqlalchemy-support-caching as the first result from Stackoverflow. Is caching using dogpile what you call "Query cache extension"? If so we don't use it. > or using the "compiled_cache" > option, There's no "compiled_cache" string in Kotti framework so I guess we don't use it. > option, *or* the error is being generated within the context of a Session > being flushed within an INSERT or UPDATE RETURNING statement, which itself I > don't think uses the traditional result set model in Oracle anyway. It's hard to say. Right before printing call stack from line 519 of result.py there's SELECT logged: 2016-04-25 16:36:02,954 INFO [sqlalchemy.engine.base.Engine][waitress] SELECT nodes.id AS nodes_id, nodes.type AS nodes_type, nodes.parent_id AS nodes_parent_id, nodes.position AS nodes_position, nodes."_acl" AS nodes__acl, nodes.name AS nodes_name, nodes.title AS nodes_title, nodes.annotations AS nodes_annotations, nodes.path AS nodes_path FROM nodes LEFT OUTER JOIN contents ON nodes.id = contents.id LEFT OUTER JOIN documents ON contents.id = documents.id LEFT OUTER JOIN files ON contents.id = files.id LEFT OUTER JOIN images ON contents.id = images.id WHERE nodes.parent_id IS NULL and right before the traceback is printed there's rollback being logged: 2016-04-25 16:36:02,975 INFO [sqlalchemy.engine.base.Engine][waitress] ROLLBACK however I don't know if it answers your last question. > any of these true for your case ? Looks like you haven't provided a stack > trace for your issue, I'm sure you have that, so send that along. Please find all information at https://gist.github.com/piotr-dobrogost/6d57cacb9e77f59748353b2b6c1334d7 Probably you are most interested in the raw log (file named "Full log from the start of the application (with empty db)"). Please note that I modified line 519 in result.py by inserting the following code: import traceback; traceback.print_stack(); to get call stack at this moment of execution. Also the nature of the bug is such that there's no information in the log about original problem (not executing some processors which were registered and executed earlier). I'm guessing there are scopes during which one should not modify the list of registered processors. If it happens that this list (as a consequence of this bug) is being cleared while one of such scopes that it would be awesome if SA could somehow notice that the list of processors was changed in some scope where it should be left intact and log warning or raise hard error. This way the reason for error would be much easier to find in this case and probably also in future. 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 sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
