Rails core - Jun 2006 - Rails AR/Oracle Unit Test: [4414] failed (but getting better)

"bitsweat" has given AR/Oracle some love, but it''s still
unhappy...

http://dev.rubyonrails.org/changeset/4414
------------------------------------------------------------------------
r4414 | bitsweat | 2006-06-02 18:02:42 -0700 (Fri, 02 Jun 2006) | 1 line

Uncry thyself
------------------------------------------------------------------------

U  activesupport/lib/active_support/core_ext/hash/conversions.rb
Updated to revision 4414.

  1) Failure:
test_to_xml(BasicsTest) [./test/base_test.rb:1231]:
<false> is not true.

890 tests, 3132 assertions, 1 failures, 0 errors
rake aborted!
Command failed with status (1): [/usr/pkg/ruby184/bin/ruby -Ilib:test:test/...]

(See full trace by running task with --trace)

Turns out that Oracle may return a Date object even if the SQL column is a 
timestamp if the hours, minutes and seconds are all 0.

The attached patch works around this. However, I don''t know if this
patch is a
good idea, with the following code in the Oracle adapter:

         def guess_date_or_time(value)
           (value.hour == 0 and value.min == 0 and value.sec == 0) ?
             Date.new(value.year, value.month, value.day) : value
         end

Does this seem like such a good idea?  I tried this:

n = Node.find(:first)
n.created_at.class => Time
n.created_at = Date.new(2006, 6, 2)
n.save
n = Node.find(:first)
n.created_at.class => Date

So while you may have a timestamp column, if you store an timestamp at midnight,
which is possible, you end up with a different object with different methods.

So maybe apply the patch to get the test to pass, but maybe we should consider 
changing Oracle''s adapter.

Regards,
Blair

Michael Schoen wrote:
> "bitsweat" has given AR/Oracle some love, but it''s still
unhappy...
> 
> http://dev.rubyonrails.org/changeset/4414
> ------------------------------------------------------------------------
> r4414 | bitsweat | 2006-06-02 18:02:42 -0700 (Fri, 02 Jun 2006) | 1 line
> 
> Uncry thyself
> ------------------------------------------------------------------------
> 
> U  activesupport/lib/active_support/core_ext/hash/conversions.rb
> Updated to revision 4414.
> 
>   1) Failure:
> test_to_xml(BasicsTest) [./test/base_test.rb:1231]:
> <false> is not true.
> 
> 890 tests, 3132 assertions, 1 failures, 0 errors
> rake aborted!
> Command failed with status (1): [/usr/pkg/ruby184/bin/ruby
-Ilib:test:test/...]
> 
> (See full trace by running task with --trace)
> 
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Blair Zajac wrote:
> Turns out that Oracle may return a Date object even if the SQL column is 
> a timestamp if the hours, minutes and seconds are all 0.
I''ve proposed a different immediate fix, patch in:

	http://dev.rubyonrails.org/ticket/5294

taking the approach that given a field type of datetime (which is what 
we have to assume within Oracle), it should always at least format as a 
datetime, even if a particular record uses a Date for the value.

#xmlschema was aliased to #to_s for Date, which seems odd; making it 
work like Time#xmlschema seems to make more sense.

I''m also thinking we should just dump the whole idea of guessing
whether
it should be a Date or Time object -- the idea that it''s inferred for 
each individual row, resulting in the possibility of different types for 
different rows, seems the worst of both worlds.

Why not just use Time, everywhere. It nearly duck-types for Date anyway.

Thoughts?

Michael A. Schoen wrote:
> Blair Zajac wrote:
> 
>> Turns out that Oracle may return a Date object even if the SQL column 
>> is a timestamp if the hours, minutes and seconds are all 0.
> 
> 
> I''ve proposed a different immediate fix, patch in:
> 
>     http://dev.rubyonrails.org/ticket/5294
> 
> taking the approach that given a field type of datetime (which is what 
> we have to assume within Oracle), it should always at least format as a 
> datetime, even if a particular record uses a Date for the value.
Do you have any URLs describing why we have to assume a datetime in Oracle?
> #xmlschema was aliased to #to_s for Date, which seems odd; making it 
> work like Time#xmlschema seems to make more sense.
> 
> I''m also thinking we should just dump the whole idea of guessing
whether
> it should be a Date or Time object -- the idea that it''s inferred
for
> each individual row, resulting in the possibility of different types for 
> different rows, seems the worst of both worlds.
Agreed.
> Why not just use Time, everywhere. It nearly duck-types for Date anyway.
I think that''s a good idea.

If we do this, then the above patch is a short term workaround, correct?

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

Blair Zajac wrote:
> Do you have any URLs describing why we have to assume a datetime in Oracle?
It''s because Oracle doesn''t have a date-only field type, DATE
is
actually a datetime. The original author made an attempt to be smart 
about whether you''d get back a Ruby Date or Time object, but
I''m not
convinced it''s possible to be that smart. Or that it makes enough of a 
difference to even try.
>> Why not just use Time, everywhere. It nearly duck-types for Date
anyway.
> 
> I think that''s a good idea.
> 
> If we do this, then the above patch is a short term workaround, correct?
Sort of. I''d still suggest the patch itself makes sense, since it keeps
Ruby Date and Time duck-typing nicely. And the patch to the test will 
still be necessary (since it recognizes that Oracle''s going to treat 
that column as a datetime, along w/ the Sybase and SqlServer adapters).

On 6/5/06, Michael A. Schoen <schoenm@earthlink.net>
wrote:
> Blair Zajac wrote:
> > Do you have any URLs describing why we have to assume a datetime in
Oracle?
>
> It''s because Oracle doesn''t have a date-only field type,
DATE is
> actually a datetime. The original author made an attempt to be smart
> about whether you''d get back a Ruby Date or Time object, but
I''m not
> convinced it''s possible to be that smart. Or that it makes enough
of a
> difference to even try.
>
> >> Why not just use Time, everywhere. It nearly duck-types for Date
anyway.
> >
> > I think that''s a good idea.
> >
> > If we do this, then the above patch is a short term workaround,
correct?
>
> Sort of. I''d still suggest the patch itself makes sense, since it
keeps
> Ruby Date and Time duck-typing nicely. And the patch to the test will
> still be necessary (since it recognizes that Oracle''s going to
treat
> that column as a datetime, along w/ the Sybase and SqlServer adapters).
>
If the Oracle adapter is going to assume a particular type for DATE
fields (and I think it should, for sure), shouldn''t it default to one
that can handle the full range of dates that the Oracle DATE type can
represent?
I know I''ve seen Rails apps that store dates prior to 1970, and there
will likely be many more in the future.

--Wilson.

Wilson Bilkovich wrote:
> If the Oracle adapter is going to assume a particular type for DATE
> fields (and I think it should, for sure), shouldn''t it default to
one
> that can handle the full range of dates that the Oracle DATE type can
> represent?
> I know I''ve seen Rails apps that store dates prior to 1970, and
there
> will likely be many more in the future.
Isn''t that (the restricted range of Ruby Time''s) a general
issue, not
just for Oracle. Store a datetime in mysql prior to 1970 and you have 
the same problem, no?

As an aside, on Debian at least Time''s go back to 1902, given
it''s
support for negative time_t.

One approach would be to catch out-of-range errors and return a DateTime 
instead of a Time. Though from what I hear, they suck (on performance). 
Again though, this seems to be a general issue, not Oracle specific.

Michael A. Schoen wrote:
> I''ve proposed a different immediate fix, patch in:
> 
>     http://dev.rubyonrails.org/ticket/5294
> 
> taking the approach that given a field type of datetime (which is what 
> we have to assume within Oracle), it should always at least format as a 
> datetime, even if a particular record uses a Date for the value.
> 
> #xmlschema was aliased to #to_s for Date, which seems odd; making it 
> work like Time#xmlschema seems to make more sense.
Can I get a commit on this? Any issues?

> > #xmlschema was aliased to #to_s for Date, which seems odd; making it
> > work like Time#xmlschema seems to make more sense.
>
> Can I get a commit on this? Any issues?
The .to_s was deliberate as the iso 8601 format for Dates without Time is
CCYY-MM-DD which is the same output as .to_s?

-- 
Cheers

Koz

Michael Koziarski wrote:
>> > #xmlschema was aliased to #to_s for Date, which seems odd; making
it
>> > work like Time#xmlschema seems to make more sense.
>>
>> Can I get a commit on this? Any issues?
> 
> The .to_s was deliberate as the iso 8601 format for Dates without Time is
> CCYY-MM-DD which is the same output as .to_s?
Ah. Any feedback then on my other question, which was how in general we 
deal with Time, given that on some platforms you can''t get a Time
before
  1972?

What do you think about the Oracle adapter just always returning Time 
(and never Date), since there isn''t a real way to determine that a Date
is what''s intended?

Only real drawback I can see is the allowed range -- ie., a Date will 
work if folks are storing really old dates, Time won''t. This could be 
handled by allowed the user to force a particular column to be treated 
as a Date, though that still breaks if folks are storing older datetimes.

Or it could just rescue a range error and return a Date in that case.

Thoughts?