I'm not sure whether this is a bug, or if I use Sequel/SQlite in a strange way. Anyway, the code below shows the issue I'm encountering and the way I've found to fix it... Is there something I get wrong?
require 'sequel' db = Sequel.sqlite db.use_timestamp_timezones=true # seen in another thread, does not change anything
db.create_table(:test){ primary_key :id column :latest_change, "timestamp with time zone", :default=>"now()".lit, :null=>false
# Explicit proc resolves the problem for me: db.conversion_procs['timestamp with time zone'] = db.method(:to_application_timestamp) puts db[:test].first[:latest_change].class # => Time
On Friday, August 3, 2012 8:26:09 AM UTC-7, blambeau wrote:
> Hi Jeremy,
> I'm not sure whether this is a bug, or if I use Sequel/SQlite in a strange > way. Anyway, the code below shows the issue I'm encountering and the way > I've found to fix it... Is there something I get wrong?
> require 'sequel' > db = Sequel.sqlite > db.use_timestamp_timezones=true # seen in another thread, does not change > anything
This is the current default, so it shouldn't change anything. I am planning to switch the default to false in the next major version, since I think using timezones in timestamps does not work with the SQLite built-in date/time functions.
db.create_table(:test){
> primary_key :id > column :latest_change, "timestamp with time zone", > :default=>"now()".lit, :null=>false > } > db[:test].insert(:latest_change => Time.now)
This is because "timestamp with time zone" is not recognized by Sequel's sqlite adapter as a timestamp type, only "datetime" and "timestamp" are recognized as such. SQLite doesn't support a native timestamp type, so I'm not sure why you are choosing to use "timestamp with time zone". The Sequel way to do what you want is:
db.create_table(:test){ primary_key :id Time :latest_change, :default=>"now()".lit, :null=>false
} > # Explicit proc resolves the problem for me: > db.conversion_procs['timestamp with time zone'] = > db.method(:to_application_timestamp) > puts db[:test].first[:latest_change].class > # => Time
If you really must use "timestamp with time zone" as your type, that's how you are going to have to handle it. I am not adding support for other timestamp type names to the sqlite adapter (what's next, "timestamp without time zone"?).
Actually, the reason I'm facing this issue is that I work with sqlite for my tests, but the sqlite database is built with a schema dump from a legacy database in postgresql.
The fact is that I'm forced to use "sequel -D" for now because the current timestamp default value (:default=>"now()".lit)is not inferred by "sequel -d".
On Friday, August 3, 2012 5:43:06 PM UTC+2, Jeremy Evans wrote:
> On Friday, August 3, 2012 8:26:09 AM UTC-7, blambeau wrote:
>> Hi Jeremy,
>> I'm not sure whether this is a bug, or if I use Sequel/SQlite in a >> strange way. Anyway, the code below shows the issue I'm encountering and >> the way I've found to fix it... Is there something I get wrong?
>> require 'sequel' >> db = Sequel.sqlite >> db.use_timestamp_timezones=true # seen in another thread, does not >> change anything
> This is the current default, so it shouldn't change anything. I am > planning to switch the default to false in the next major version, since I > think using timezones in timestamps does not work with the SQLite built-in > date/time functions.
> This is because "timestamp with time zone" is not recognized by Sequel's > sqlite adapter as a timestamp type, only "datetime" and "timestamp" are > recognized as such. SQLite doesn't support a native timestamp type, so I'm > not sure why you are choosing to use "timestamp with time zone". The > Sequel way to do what you want is:
>> # Explicit proc resolves the problem for me: >> db.conversion_procs['timestamp with time zone'] = >> db.method(:to_application_timestamp) >> puts db[:test].first[:latest_change].class >> # => Time
> If you really must use "timestamp with time zone" as your type, that's how > you are going to have to handle it. I am not adding support for other > timestamp type names to the sqlite adapter (what's next, "timestamp without > time zone"?).
On Friday, August 3, 2012 9:43:28 AM UTC-7, blambeau wrote:
> Thanks for your answer.
> Actually, the reason I'm facing this issue is that I work with sqlite for > my tests, but the sqlite database is built with a schema dump from a legacy > database in postgresql.
> The fact is that I'm forced to use "sequel -D" for now because the current > timestamp default value (:default=>"now()".lit)is not inferred by "sequel > -d".
I always recommend testing using the same database type you are using in production, as it avoids a lot of problems.
Still, the root cause of your problem is that Sequel doesn't translate 'now()' to a generic ruby value. It would be helpful if that were translated to Sequel::CURRENT_TIMESTAMP when -d is used. I've added that to my todo list, it should hopefully make it into the next version.
On Friday, August 3, 2012 10:36:23 AM UTC-7, Jeremy Evans wrote:
> Still, the root cause of your problem is that Sequel doesn't translate > 'now()' to a generic ruby value. It would be helpful if that were > translated to Sequel::CURRENT_TIMESTAMP when -d is used. I've added that > to my todo list, it should hopefully make it into the next version.
