Thanks both. It's nice to know that I wasn't missing something and the mysql gem really is just kind of a pain in the behind.
I looked at the mysql2 gem and, dang, yeah, that's what it's supposed to be like. In my case though, I've been specifically tasked with making this thing as little of a moving target as possible and from some googling I get the impression I'm just a little early for mysql2. It turns out though that if you use Mysql's prepare/execute (instead of query) that you get a result that's a little more usable. The time fields are Mysql::time objects rather than just strings. But at least they're easily identifiable as time-related. As per my mail a couple of days ago though, you can't iterate over those results as hashes. So I'm wrapping my select queries in code that: a) gets the column name information and maps the array indices to those names, then builds a hash keyed on the names b) when it finds a Mysql::time value, it converts that to a DateTime value So the result is a more ruby/rails-y hash of ruby data types. Kinda like mysql2 gives you out of the box. :-) -glenn On Fri, Aug 27, 2010 at 3:48 PM, Nick Zadrozny <[email protected]> wrote: > Hi Glenn, > How about DateTime.parse? Or, if you're in Rails, Time.zone.parse. While a > lexical approach will certainly work, I'd personally prefer to do the proper > logical type casting in a situation like this. > Even still, it's a bit ugly. > If you want to take care of the typecasting issue at its source, you might > want to take a look at the mysql2 adapter. It's new and intended as a > drop-in replacement for the mysql adapter. It does better Ruby typecasting > (read: it does Ruby typecasting), which is exactly what you're looking for > here. Also, its result sets extends Enumerable, and it handles character > encodings correctly in Ruby 1.9. In short, it's very Ruby-ish. > It's pretty young and apparently under active development, which might throw > you off, depending on what you need it for. I'm not using it in production > quite yet, but that's probably because I don't have a whole lot of need to > use the mysql adapter directly. When I start to migrate my apps to Rails 3 > and Ruby 1.9.2 I'll probably switch to the mysql2 adapter as well. > Beyond that, I'll let its docs and author speak for it: > http://github.com/brianmario/mysql2 > http://stackoverflow.com/questions/3001243/ruby-rails-mysql2-gem-does-somebody-use-this-gem-is-it-stable > Yehuda also mentions mysql2 with respect to character encoding and thread > safety: > http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/ > -- > Nick Zadrozny > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
