Closed ottworks closed 5 years ago
Moan at Rubat or Kilburn or validate your results using tobool, not a major issue since you should be validating types anyway.
No, you're wrong. When I store true, I expect Where(true) to find that result. I can't fix this without modifying the wrapper, in which case you've failed. On Dec 25, 2015 3:30 AM, "Alex Grist-Hucker" notifications@github.com wrote:
Moan at Rubat or Kilburn or validate your results using tobool, not a major issue since you should be validating types anyway.
— Reply to this email directly or view it on GitHub https://github.com/alexgrist/GLua-MySQL-Wrapper/issues/4#issuecomment-167224090 .
Failed? It's a simple and easy to use SQL wrapper which makes writing queries for each different module an easy task, if you can't check your result types because SQLite returns a boolean value differently then that's a failure on your part not mine.
I prefer the wrapper to persist the value types returned by the original modules... makes more sense.
MySQL doesn't even store Boolean values, how do you expect a "where" clause to find a type that MySQL doesn't even know about. How has he failed? I'm dying to know.
Because SQLite does. MySQL stores it as aptinyint(1), however the wrapper doesn't let you know that and just silently converts it. Am I correct that a wrapper is supposed to provide a generic frontend that behaves consistently?
Well what happens if you want to store and retrieve an aptinyint that isn't true and false? Think of all the use cases. It's silly enough you're trying to stuff a boolean value into a MySQL table. Don't use bools if some of the modules you want to support don't support them.
Am I correct that a wrapper is supposed to provide a generic frontend that behaves consistently?
No, not at the expense of breaking other things for your feature request.
SQLite uses true/false but mysqloo uses 1/0. The wrapper fails to translate.