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 [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/55141736-3ea8-4de6-8d8d-02081de10153%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to