On Friday, July 20, 2018 at 3:12:30 AM UTC-7, [email protected] wrote: > > Hi Jeremy > > Thanks for the prompt response. Good to see the gem is well supported. > I've been on other things since Wednesday, but should be cracking on with > this from Monday. > > I'm still hunting where ruby objects are converted for delivery to the > jdbc layer, and I think I've just found an ideal place to detect that an MS > datetimeoffset has been loaded, so I can control its conversion. > > After thinking about this for a while, I'm aiming to have a switch that, > if enabled, handles the timestamps more formally: > > MS SQL date => Ruby Date => a suitable MS date literal form. > As per current behaviour. > > MS SQL datetime (and datetime2 et al) => Ruby Time => MS SQL datetime > literal > As per current behaviour. > > MS SQL datetimeoffset => Ruby DateTime with timezone offset unchanged. > Ruby DateTime => MS SQL datetimeoffset literal (basically the ISO format) > > It will be strict in the sense that the developers must pay more attention > to using the correct Ruby classes; datetime will not be assumed to suit use > for an MS datetime type once the switch is set. This would be a breaking > change for many projects, so it needs to be enabled explicitly with a > switch. > > For the application, I need a clear distinction between a Ruby Time type > and the Ruby DateTime. The Ruby Time is to be used with localtime offset > for server-related stamps such as schedules and audit data). The Ruby > DateTime will be used to faithfully record the data that can be collected > from various timezones, and needs to carry its local offset so that > questions like "all data for Monday" can be easily accommodated without > having to laboriously code conversions from a fixed offset and a separately > stored locality indicator. I know conventional "wisdom" which is splattered > all over the Internet says to convert everything to UTC, but the loss of > locality information is not acceptable for this application. > > Ideally, the code needs to be written so that other engines with a > datetimeoffset can play the same game if someone else makes the adapters. > > I guess my main concern is that I find all the locations in the code that > marshal the objects to and from the JDBC, and that the setting can be used > at the connection, db and possibly statement level as so many of the > extensions and settings can. >
That's basically just overriding Dataset#literal_datetime, and if you want to handle prepared statement arguments/bound variables, Database#set_ps_arg (jdbc adapter specific). You would want to add this as a Database extension that just overrides those two methods. That doesn't require a fork of Sequel, external extensions are treated the same as internal extensions. See http://sequel.jeremyevans.net/rdoc/files/doc/extensions_rdoc.html Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
