You'll want to have login as a field and created_at as an attribute in
your define_index block:
define_index do
# ...
indexes login
has created_at
end
And then you can search like so:
User.search :conditions => {:login => 'foo'}, :with => {:created_at =>
(1.month.ago..Time.now)}
Cheers
--
Pat
--
Pat
This is how I described the issue back then:
http://rubyforge.org/forum/message.php?msg_id=50481
(Ultra)sphinx assumed the times in the database were in the same time
zone as MySQL was configured for (typically machine-local time). It
did not care that Rails was configured to treat database dates as UTC.
Note that MySQL doesn't store time zones in the date columns, and
they're not (time zone agnostic) timestamps, so there must be some
external definition of the time zone.
So if I created a record at 10 am local time (Sweden), it might be
stored in the database as 8 am (UTC). Since Rails was configured to
treat database times as UTC, it knows this means 8 am UTC. But since
MySQL is configured for machine-local time, outside ActiveRecord it
thinks it means 8 am Swedish time.
Ultrasphinx would make the same misassumption, and so filtering could
be off by a few hours.
Again, haven't looked at how Thinking Sphinx deals with this, but it's
something to be aware of. So either make sure MySQL and Rails are
configured for the same database time zone, or add offsets to time
filters.
My workaround was to do
UTC_OFFSET = Time.now.utc_offset
in an initializer (before changing ENV['TZ'], if you do that) and then
modifying the values in the range by that.
Added to my task list.
--
Pat
Sorry
--
Pat
Time.now..Time.mktime(2038)
2038 is the last year Ruby's Time class supports. I'm not sure what
limitations MySQL and Sphinx have in that respect. If you need a
higher end date and they support it, I'm sure you could use the actual
timestamps instead of Times.