On 26 March 2014 10:10, Florian Apolloner <[email protected]> wrote:
> On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: >> >> Firstly -- can we assume anyone using this feature is not a complete >> novice, and so will take the caveats mentioned into consideration? >> > > Yes > > >> 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. >> > > Assume connection drops don't exist for now. How can/will Django know if a > query is prepared already and when does it have to prepare it, or do you > expect me to issue a PREPARE statement everywhere I use it and handle the > error if it already exists?! I can easily see this working for management > scripts, but not for web requests which are possible routed through pgpool > etc… [That said, I have no real experience with those things, but I'd like > to know how this can work] > I had been working from the perspective that as soon as you call prepare() on the QuerySet, it will prepare the statement. I can find some bug reports for pgpool to do with unnamed prepares, but [oddly] can't find docs about unnamed prepares. Even if the first implementation is simply: Provide the API, document the caveats, it's at least a good first step upon which we can test how the various drivers support it, dbs interact, and error conditions explode. > 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. >> > > See above, how can you reliable determine if this assumption holds up? > As they say in electricians school: suck it and see. :) > > 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. >> > > What do you mean by "single connection", persistent connections are single > connections and as you said above prepared statements are local to the > connection/session anyways… > And I would expect the prepared statement to persist between requests in that case. If I thought we could rely on DB dis/connect signals [maybe we can, I don't know yet] we could teach prepared statements to track that and re-prepare themselves on first use. Just throwing ideas out there... seeing which ones excite :) -- C -- 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_XiSCN%2BOOV%3Drmr86vkXL8MwycSjjHRfJbMuGkVnXF1D0F72g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
