Just thought I'd mention that mysql2 was just set as the default mysql adapter for Rails 3 (as of RC2 released the other day). While that doesn't guarantee that it's not a moving target, it's getting pretty solid and I would definitely push for switching to it if at all possible. You also may encounter encoding issues when using the original mysql gem if you attempt to use it with Ruby 1.9.2.
James On Fri, Aug 27, 2010 at 6:17 PM, Glenn Little <[email protected]> wrote: > 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 > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
