On Tuesday, December 11, 2012 4:04:34 PM UTC-8, Russell Fulton wrote: > > > > For complex static cases targeting a single database, literal SQL is often >> going to look and work better. The advantage of Sequel's DSL is it is >> database independent (in some cases) and it makes it easier to handle >> dynamic cases. >> >> > > thanks Jeremy! this is basically the conclusion that I came to -- in this > particular case I need the date functions and the whole ruby wrapper class > is less than 50 lines so abstracting the database stuff is not that bigger > win. I will persist with sequel for some other applications. > > And providing some simple standardised date manipulation stuff would be a > "Good Thing" (tm) :) >
I've just committed an extension that allows for some database independent date calculations: https://github.com/jeremyevans/sequel/commit/0172eccd59337b5668a781331ae284b3616359fb > > Hmm... just checked the version: > > [rful011@itslogprd05 ~]$ gem list > > *** LOCAL GEMS *** > > bundler (1.2.2) > dbd-mysql (0.4.4) > dbi (0.4.5) > deprecated (2.0.1) > httparty (0.9.0) > multi_json (1.4.0) > multi_xml (0.5.1) > mysql (2.9.0) > rake (10.0.2) > rubygems-bundler (1.1.0) > rvm (1.11.3.5) > sequel (3.42.0) > > which I think *is* the latest. > > so I am not sure what is happening with function? > Me either. What does Sequel.version show? Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/ewvXYo0X02sJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
