On Fri, Oct 27, 2017 at 4:34 AM, Warren Young <[email protected]> wrote:
> Before I get to the questions, I haven’t listened to the FLOSS episode > yet, so please forgive me if these were asked and answered on the podcast. > Just tell me if so, because I will eventually get to it. > > 1. I don’t see a C API. If so, that means it’s up to the caller to handle > quoting and escaping properly to avoid inadvertently creating SQL injection > vulnerabilities. Is that true, and if so, is there a plan to solve it? I > don’t mind running my queries through an HTTP[-ish] layer, but getting > quoting and escaping right in hand-written code is a big source of errors > I’d rather not return to. > There is a PHP binding (https://github.com/Expensify/Bedrock-PHP) but none for C yet -- PRs welcome! That said because it uses standard HTTP escaping it should also be compatible with pretty much any HTTP C API -- or it's very easy to hand roll. When it comes to escaping, for example, you can generally put the content directly in the HTTP content body, so Bedrock introduces no "extra" escaping (beyond what is normally required by SQL, of course). > 2. No DBD::BedrockDB yet, I see. When? :) > Heh, we don't have much Perl in our environment, but again, this would be straightforward to add. > 3. What happens if a local program attaches to the SQLite DB and queries > it in the face of active replication? > SQLite is crazy hardened and reliable in this scenario. You are free to access the underlying SQLite database via the command line if you like, but the locking behavior will be more restrictive. BedrockDB not only supports concurrent reads (via SQLite's standard WAL functionality), but concurrent *writes* as well (via an experimental "BEGIN CONCURRENT" branch developed by the SQLite team that we're hammering the kinks out of before its merged into the mainline). So use the Bedrock plugin architecture where possible to get maximum concurrency, and never do writes from the command line as it'll screw up our replication journal, but you are free to do reads via the command line when more convenient (and we do it all the time). 4. What happens if a local program *inserts* data via the SQLite > interface? Does the data get replicated, or does that happen only if you > insert via port 8888? > Correct, only insertions done via port 8888 will get replicated, so it's not recommended (but always possible for extreme maintenance scenarios -- about as often as you'd directly modify a local MySQL file with a hex editor -- meaning, almost never). > 5. I think your web pages answer this one implicitly, but let me ask just > to be sure I’m guessing right: Does the MySQL API smooth out any of the > semantic and language differences between MySQL and SQLite, or must you > simply give SQLite-compatible queries over the MySQL interface? (Expected > answer: “No.”) > No -- we only support SQLite syntax (which is really more modeled off of Postgres), but in practice the various MySQL clients we've tried don't actually care about the syntax -- only the protocol -- so it works well enough in practice. 6. What MySQL API version are you compatible with? As maintainer of > MySQL++, I can tell you, there is not just one version. :) > Good question, we don't have an exhaustive list. The versions we use, at least. :) But the most recent version of SequelPro, the MySQL command line client that ships with Ubuntu, and Mode Analytics to start. > 7. Does using your MySQL API solve problem #1? That is, if you use one of > the available ways for constructing guaranteed-sound queries via > libmysqlclient or one of the many libraries built atop it, does BedrockDB > get the benefit? > I'm not sure what "guaranteed-sound" means, sorry! > 8. Does your MySQL API solve problem #2? That is, have you tested it > against DBD::mysql? > I don't think we've tested against that as we don't use a lot of Perl, but I'd be curious for your results! -david Founder and CEO of Expensify (and BedrockDB) _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
