On Oct 11, 5:02 pm, Nate Wiger <[email protected]> wrote:
> > With Sequel, there's not much of an advantage to binding variables
> > unless the variables are expensive to literalize (e.g. large blobs).
> > And I think the decision about whether to prepare a statement should
> > be up to the user, as preparing all statements would most likely
> > decrease performance for the average user.
>
> > With the current code base, the user makes the decision of which
> > variables should be bound and which statements prepared, so they can
> > choose the cases to optimize. It's assumed that the user is profiling
> > the app to determine when to use the bound variable/prepared statement
> > support, and benchmarking before and after to make sure that using
> > bound variables/prepared statements is faster. I strongly discourage
> > using bound variables/prepared statements unless you have profiled
> > your application and found a bottleneck that using bound variables/
> > prepared statements can eliminate or decrease.
>
> Do you work with databases like Oracle and Postgres where native bind
> variable support is a huge advantage basically across the board?
I run all of my production applications on PostgreSQL, though
performance isn't an issue for any of them.
You should understand that performance is not a primary goal of
Sequel. Simplicity, flexibility, and power all take precedence.
> There are no situations in Oracle where forcing a hard parse is
> preferable to bind variables, even for a one-time "throwaway" query.
I have almost no experience with Oracle, so I wasn't aware of this.
My understanding of Oracle's statement execution was that preparing
statements made the most difference, because of the work the query
planner does. Using bound variables without prepared statements still
requires parsing the rest of the string. So are you referring to
using bound variables with prepared statements, or without? For
simple things like integers and strings, how significant is the
performance difference in the bound variables without prepared
statements case (e.g. 2% faster, 20% faster, 200% faster)?
> I'm a bit surprised by your response to be honest. In terms of
> backwards compat, I threw together quick mockups for the major
> adapters (mysql/sqlite/postgres/oracle) and all of them threw errors
> on "id < :min and id > :max". So there's not compat to keep for 95+%
> of cases, since Sequel generates errors as-is.
The backwards compatibility is not when using "id < :min and id
> :max", but when providing a string to filter that didn't have a
named placeholder along with a hash argument (see the example I
posted). And like I said, the backwards compatibility is not a major
concern, since I doubt the types of scenarios where backwards
compatibility would be broken are common.
I just feel that the literal string with named placeholders and a hash
is just not nearly as necessary in Sequel as it is in AR (Sequel
offers a lot nicer syntax for the constructs you mentioned). I can't
recall any other requests for string with named placeholders. As I
mentioned, I'm not opposed to adding it if there is broad community
support.
> If you're not interested in advancing Sequel, that's ok, just let me
> know and I'll fork the adapter accordingly.
Implying that I'm uninterested in "advancing" Sequel is disingenuous
at best. Sequel's development probably proceeds at a quicker pace
than either AR or DM, in spite of the fact that I do 90% of the
development myself.
I'm willing to consider your patches, even ones that introduce new
APIs or change current behavior. However:
1) The changes have to be consistent. Treating placeholder literal
strings differently than all of the other syntax constructs Sequel
offers is a no-go.
2) Any new features have to work on all adapters.
3) The changes have to pass existing specs.
4) Any new features need to have 100% spec coverage and good
integration test coverage.
5) The implementation complexity shouldn't be too high (subjective).
I'm not against the following API for bound variables assuming that
the above points hold:
Dataset.filter{id > :$id}.bind(:id=>1).all
What I am more concerned with is:
Dataset.filter{id > 1}.all
Dataset.filter("id > ?", 1).all
Dataset.filter("id > :id", :id=>1).all
binding variables. I'm concerned about that not because I'm against
bound variables, but because I understand Sequel's architecture and
think that it would be very hard to use bind variables in those cases
and have the above points hold. I'd happily consider an
implementation that used native bound variables implicitly if the
above points hold.
Preparing statements implicitly is different issue, but I suppose the
same principles apply. I think that would be even more difficult,
though.
I suppose I should refine my original statements to say that I'm
against implicit bound variable/prepared statement support not for
philosophical reasons, but for pragmatic ones that could potentially
change.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
