Firstly, I mostly proposed this API in response to others calls for it. Yes, I'd love to have it, but I'm content to leave it in the "too hard" basket.
That said, it doesn't mean I'm not going to try to solve these issue :) So: Firstly -- can we assume anyone using this feature is not a complete novice, and so will take the caveats mentioned into consideration? Yes, prepared statements are local to their connection/session. And would be expected to "go away" should the connection drop. However, in most cases connection drop-out is quite rare [at least, in my experience], and would be even more rare in the case of people using certain connection pooling tools. Assuming it's not fatal to a transaction, would it be feasible for a prepared statement to work on the assumption is has been prepared, and if it hasn't, prepare itself and continue? I'd prefer this to, for instance, having PS listen for connection closed signals. Having to prepare the statement via connection would certainly drive home its binding to it, but I'm not sure many people think about connections as transient [happy to be proven wrong here :)] Further, as an "expert" feature, would it be unreasonable to limit its use to cases where you know it will benefit, but also only be used in a single connection? True, this limits its use cases somewhat, but it's still available when of benefit. As to Jeremy's idea of multiple shapes of a single prepared query based on _potential_ arguments, I disagree. Much safer [and easier to code] to detail in the documentation that "because we can't guess at values, you can't rely on these ORM shortcuts". Michael: Perhaps there are more docs you are referencing, but what you quote there says to me there's little benefit to preparing statements on MSSQL, not that they actively discourage it. Certainly, I agree there should be the ability for PS to behave as a canned QuerySet in cases where the backend does not support them. It's safe, easy, and low-surprise. -- Curtis On 26 March 2014 06:36, Shai Berger <[email protected]> wrote: > On IRC, @apollo13 asked some very good questions about the lifecycle of > prepared statements. I would like to elaborate. > > Prepared statements usually live on the server, in the context of a > session -- > which, for Django, means they're only valid in the thread where they were > built; without persistent connections, this would mean "only valid during > the > processing of one request", but even with them, connections are sometimes > dropped. So, prepared statement objects cannot really be long-lived and > reused > across requests. > > So, I suspect the API: > > > ps = MyModel.objects.filter(foo__lt=Param('a')).prepare() > > Has good chances to become a mini-footgun -- it all-but tells users > "prepare > me once, use me forever", but you really can't do that. It will pass tests > (run in a single thread over a single connection), and crash in production > -- > unless a prepared statement can somehow be aware of the connection state, > and > take some measures (I don't currently see which) against it. > > The main benefit of prepared statements comes when you can prepare them > once > then use them many times (with different parameters); but this is very > atypical > for Django apps (within a single request). I think if we want this > feature, we > should "brand" its API as something for special uses, and give the right > hints > about its link to the database session -- so, something like > > qset = MyModel.objects.filter(foo__lt=Param('a')) > ps = connection.prepare(qset) > > or maybe even > > ps = connection.cursor().prepare(qset) > > and also for execution: > > results = cursor.execute(ps, a=7) > > My 2 cents, > > Shai. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/201403252136.50615.shai%40platonix.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSBwBfWSUFdEzLqyc3nOH1WBf%2B6N77VRijbAbLq9TL4i-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
