DateTime and date/time fields
I noticed with Sequel 2.0 that the Ruby object for a Postgres timestamp field is now a DateTime instead of a Time object. Is DateTime the default for all date and time related fields or is Time and Date objects used in other cases? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: DateTime and date/time fields
On Jun 2, 7:56 am, Farrel [EMAIL PROTECTED] wrote: I noticed with Sequel 2.0 that the Ruby object for a Postgres timestamp field is now a DateTime instead of a Time object. Is DateTime the default for all date and time related fields or is Time and Date objects used in other cases? The value you get from the database is adapter specific (I think Time is used in most cases). When using models with typecasting, it will always cast to a DateTime and not a Time. I'll accept patches for adapters to use a DateTime field instead of a Time field. Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: literal method
For reference, here's the literal method from Sequel::MySQL::Dataset:
# File sequel_core/lib/sequel_core/adapters/mysql.rb, line 310
310: def literal(v)
311: case v
312: when LiteralString
313: v
314: when String
315: '#{::Mysql.quote(v)}'
316: when true
317: TRUE
318: when false
319: FALSE
320: else
321: super
322: end
323: end
There's no reference in their to the implicit self (dataset) or any
other Dataset methods. It takes a parameter v and returns a simple
derivative, in one case calling a Database method. It doesn't do
anything with the Dataset instance. Therefore, it should not be a
Dataset method, especially when there is a valid and important use
case for it to be made more easily available in the Database classes.
Thanks,
Shawn
p.s. And yes, you could say that we should just execute the odd raw
SQL statement directly through the 'mysql' class, but why, when Sequel
already has methods to do it? The ideal solution here is to allow
developers to use Sequel both for its great high-level functions and
for the occasional low-level SQL statement. Surely we can make this
easier and not force developers to use datasets when they don't need
them, just because our Sequel world so often is Dataset-centered.
On Jun 1, 8:14 pm, Jeremy Evans [EMAIL PROTECTED] wrote:
On Jun 1, 3:25 pm, Shawn [EMAIL PROTECTED] wrote:
Since the existing literal method in Sequel::Dataset makes no
reference to the dataset from which it is invoked, it makes more sense
for the entire method to be moved to Sequel::Database, and for
Sequel::Dataset to get a new literal method that calls
Sequel::Database::literal. Do you agree?
No. The reference is the implicit self, which will be an instance of
the subclass of Sequel::Dataset specific to the database adapter being
used. I think all of the adapters override Dataset#literal in their
dataset subclass, so if you want customizable behavior, it's already
there, just modify the dataset method in the adapter's dataset
subclass.
This is fairly standard OO design, I'm not sure why there is much
confusion. I've already explained the reasoning behind the choice,
and there would have be a very good reason to change it, considering
that a work around is fairly simple (adding a database method that
calls a dataset method). I don't want to discourage any attempt at
persuasion, but I highly doubt that any line of reasoning could
convince me that there is enough reason to change it, even if I
believed that the method belongs in Database and not in Dataset (which
I don't).
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: literal method
Sorry for the multiple messages. Couple more points, though, before I
go to bed:
1. Even though Sequel::MySQL::Dataset's literal method doesn't refer
to the dataset instance, it would be prudent to check that the other
adapters' datasets' implementations of literal also do not refer to
the dataset instance or use any Dataset methods. I'm happy to do that
after I've had some sleep.
2. Yes, I could use MySQL.quote to prepare user input for raw SQL, but
this would lose the database engine abstraction that Sequel provides.
If I switch to another database later on, I'd have to change all the
MySQL.quotes to something else for the new engine. Being able to call
DB.literal would be much better design, to preserve the engine
abstraction and improve maintainability.
Not to mention, it looks a lot cleaner to have everything be a
reference of the DB connection:
DB = Sequel.open ...
DB.execute(INSERT INTO #{db.literal(params[...])} ...)
DB[SELECT * FROM table1 JOIN table2... WHERE
table1.key=#{db.literal(params[...])} ...].each ...
It makes no sense to create a dataset just to get at the literal
method; such a dataset wouldn't be used for any other purpose, since
the SQL statements are executed by calls to the DB object. It makes
the code more cluttered and less readable to change each db.literal
into a db[:some_table].literal, and wastes cycles and memory creating
a dataset that won't be used for any true Dataset-specific behavior.
I hope some of the points I've made tonight, and the above intended
use case, will merit further consideration for moving the literal
method from Dataset to Database.
Thanks,
Shawn
On Jun 1, 8:14 pm, Jeremy Evans [EMAIL PROTECTED] wrote:
On Jun 1, 3:25 pm, Shawn [EMAIL PROTECTED] wrote:
Since the existing literal method in Sequel::Dataset makes no
reference to the dataset from which it is invoked, it makes more sense
for the entire method to be moved to Sequel::Database, and for
Sequel::Dataset to get a new literal method that calls
Sequel::Database::literal. Do you agree?
No. The reference is the implicit self, which will be an instance of
the subclass of Sequel::Dataset specific to the database adapter being
used. I think all of the adapters override Dataset#literal in their
dataset subclass, so if you want customizable behavior, it's already
there, just modify the dataset method in the adapter's dataset
subclass.
This is fairly standard OO design, I'm not sure why there is much
confusion. I've already explained the reasoning behind the choice,
and there would have be a very good reason to change it, considering
that a work around is fairly simple (adding a database method that
calls a dataset method). I don't want to discourage any attempt at
persuasion, but I highly doubt that any line of reasoning could
convince me that there is enough reason to change it, even if I
believed that the method belongs in Database and not in Dataset (which
I don't).
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
not_naughty with 2.0
I'm having trouble getting my models to load up with sequel 2.0 and not_naughty 0.5.1 downloaded from rubyforge. It appears there has been some interface changes and not_naughty might need to be updated. Here is the error I get NoMethodError: undefined method `def_hook_method' for Tester:Class from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:88:in `included' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:87:in `instance_eval' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:87:in `included' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:76:in `include' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:76:in `send!' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/ sequel_not_naughty.rb:76:in `apply' from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/sequel-2.0.0/lib/ sequel_model/plugins.rb:25:in `is' from ./tester.rb:14 from (irb):1:in `require' from (irb):1 Has def_hook_method recently been dropped? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: not_naughty with 2.0
On Jun 2, 8:59 pm, dusty [EMAIL PROTECTED] wrote:
I'm having trouble getting my models to load up with sequel 2.0 and
not_naughty 0.5.1 downloaded from rubyforge. It appears there has
been some interface changes and not_naughty might need to be updated.
Here is the error I get
NoMethodError: undefined method `def_hook_method' for Tester:Class
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:88:in `included'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:87:in `instance_eval'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:87:in `included'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `include'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `send!'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `apply'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/sequel-2.0.0/lib/
sequel_model/plugins.rb:25:in `is'
from ./tester.rb:14
from (irb):1:in `require'
from (irb):1
Has def_hook_method recently been dropped?
I don't think it is used any more. Hooks methods are defined via:
instance_eval(def #{hook}(method = nil, block); add_hook(:#{hook},
method, block) end)
not_naughty probably needs to be updated.
Note that if the only reason you are using not_naughty is for
conditional feature (:if option), that's going to be added to the
default validations fairly soon. dtsato has a branch at github that
implements it, I'll be merging it after I have some more time to
review it and test it.
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: not_naughty with 2.0
On Jun 3, 12:05 am, Jeremy Evans [EMAIL PROTECTED] wrote:
On Jun 2, 8:59 pm, dusty [EMAIL PROTECTED] wrote:
I'm having trouble getting my models to load up with sequel 2.0 and
not_naughty 0.5.1 downloaded from rubyforge. It appears there has
been some interface changes and not_naughty might need to be updated.
Here is the error I get
NoMethodError: undefined method `def_hook_method' for Tester:Class
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:88:in `included'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:87:in `instance_eval'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:87:in `included'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `include'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `send!'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/not_naughty-0.5.1/lib/
sequel_not_naughty.rb:76:in `apply'
from /opt/ruby-1.8.7/lib/ruby/gems/1.8/gems/sequel-2.0.0/lib/
sequel_model/plugins.rb:25:in `is'
from ./tester.rb:14
from (irb):1:in `require'
from (irb):1
Has def_hook_method recently been dropped?
I don't think it is used any more. Hooks methods are defined via:
instance_eval(def #{hook}(method = nil, block); add_hook(:#{hook},
method, block) end)
not_naughty probably needs to be updated.
Note that if the only reason you are using not_naughty is for
conditional feature (:if option), that's going to be added to the
default validations fairly soon. dtsato has a branch at github that
implements it, I'll be merging it after I have some more time to
review it and test it.
Jeremy
Thanks for the update. That does happen to be the only reason I was
going to use it. I was going to try to roll one myself, but thought
I'd give not_naughty a look at first. I am looking forward to the
merge and I appreciate the heads up!
-Dusty
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
