> 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? There are no situations in Oracle where forcing a hard parse is preferable to bind variables, even for a one-time "throwaway" query. 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. If you're not interested in advancing Sequel, that's ok, just let me know and I'll fork the adapter accordingly. -Nate --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
