extensibility for ORM evaluator

[eevee]

Current problem I'm having is that it doesn't know how to evaluate op("&"), but from the looks of it, it also won't understand hybrid properties (which would seem to exist for exactly this purpose!) or custom operators or custom ClauseElement subclasses. There doesn't seem to be any way to extend it at all, and it's barely been updated since it was written.

[Mike Bayer]

it wont understand op("&"), that is true. But as far as hybrids, those should have nothing to do with it, as a hybrid property only produces a SQL expression, and that's all the evaulator sees.

ive never really seen anyone actually needing query.update() or delete() to do evaluation, people just set synchronize_session=False. that's not a default because i like the user to agree that doing a bulk update/delete means their in-python state usually can't be updated very efficiently.

anyway the evaluator is pretty simple and im sure you can propose a nice extension system for it, how about something similar to @compiles ? we also have been waiting for years for someone to implement in_().

[Mike Bayer]

targeting this at 1.0 for the moment, as its a feature add. it can be backported to 0.9 if we come up with something simple and risk-free.

[eevee]

It's not terribly important, but this codebase seems to be treating synchronize_session=False as a magical incantation you just have to use when you do a bulk update, and when that happens I feel the urge to fix something. :)

Would be nice if the extension system could take advantage of something that already exists, which is why the non-handling of hybrids seems like a missed opportunity. I'll have to play around after this project manages to upgrade to 0.9.

[Mike Bayer]

well lets appreciate why that is. someone says query.update(Foo).values({'bar': 'hoho'}). Then three lines later they have a Foo() object lying around and foo.bar is not the value 'hoho'! silent failure! hence we force the user to essentially click the EULA for the bulk update feature :)