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]

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?

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…

 

> 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".
>

Ditto.

Florian

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/55141736-3ea8-4de6-8d8d-02081de10153%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to