-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why doesn't "update ... where column = ?" take all of a sudden? #525
Comments
@flavorjones: So some commit between the two introduces the (major) issue. How does one require a local Git repository? Wanted to bisect, but got "couldn't find sqlite3_native". |
@forthrin Thanks for opening this issue. I'm looking into it now. |
@forthrin OK, as noted in the CHANGELOG for 2.0.0, we removed some deprecated APIs, specifically non-array binding parameters. If you run this script with sqlite3 v1.7.3 with warnings enabled, you'll see:
So if you update the script to wrap the binding parameters in an array: db.query('update foo set value = ? where key = ?', ['YES', 1]) then you'll see the warning go away, and this code will work with both old and new versions of sqlite3. |
I'm worried that the gem isn't giving a better warning when this happens, so I'm looking into raising an exception if the right number of bind parameters isn't passed. |
@forthrin Original commits deprecating this are from 2010: and the reason appears to be compatibility with the sequel gem. Maybe @tenderlove remembers the context. |
Were it only way to ensure some aspect of security, one would have to concede, but ... compatibility with another gem? Brackets in this context seems superfluous and not in the pristine spirit of Ruby. It just looks and feels bad. What is the real cost and consequence of reverting the change? |
I'm sorry that this surprised you, and I understand that you disagree with the API decision. Further, I acknowledge that this code should be raising an exception and is not -- see #527 for a proposed fix for that. @tenderlove and I are going to talk about whether to revert this or not. But: this is a major release. The CHANGELOG stated what changed and provided advice on how to upgrade. This change has been waiting fourteen years for a major release so that we would have the opportunity to finish it. We may choose not to revert and I want you to be prepared for that. |
I'd prefer we don't have a db.query('update foo set value = ? where key = ?', 'YES', 1) Or like this: db.query('update foo set value = ? where key = ?', ['YES', 1]) I would like there to be only one way to use a particular method. |
Granted, people (with sufficient verbosity settings) have had eight Taylor Swift albums worth of time to prepare. @tenderlove: Can you share:
"What Would Matz Do?" |
v2.0.1 will raise an exception in these cases. |
@tenderlove: Would really appreciate your list of underlying considerations that necessitated this change. |
@forthrin sorry, I don't feel I owe you anything more than what I've commented. As I said "I would like there to be only one way to use a particular method." This has been deprecated for years, and this is a major version bump. If you don't want to change your code, don't upgrade. |
It is simply unclear what specific ambiguity you are implying (ie. "what the caller meant"), when no code examples are given to illustrate this. Your reluctance to give a friendly and simple technical explanation is duly noted. I'll stay on upgrades but keep a reversion of this particular change to keep my code clean and Ruby-like. EOF |
The text was updated successfully, but these errors were encountered: