Trying to make sure my revised oracle_adapter passes all tests, and I''m
running into an issue with test/calculations.rb.
Calculations itself seems to work fine. The problem is that the the
tests presume that the values returned by things like "group by
firm_id"
are always strings.
In Oracle, the adapter is able to detect the datatype, and returns back
the "right" type, rather than just strings. I''m assuming that
mysql just
treats these as strings?
As an example, if I change:
def test_should_calculate_grouped_with_invalid_field
c = Account.count(:all, :group => ''accounts.firm_id'')
assert_equal 1, c[''1'']
assert_equal 2, c[''6'']
assert_equal 1, c[''2'']
end
to:
def test_should_calculate_grouped_with_invalid_field
c = Account.count(:all, :group => ''accounts.firm_id'')
assert_equal 1, c[1]
assert_equal 2, c[6]
assert_equal 1, c[2]
end
then it works just fine for me.
If somebody (Rick?) can confirm I understand the issue properly, I''ll
make the unit tests pass for Oracle by hacking the tests if the current
adapter is Oracle.
On Feb 28, 2006, at 6:02 PM, Michael Schoen wrote:> Trying to make sure my revised oracle_adapter passes all tests, and > I''m running into an issue with test/calculations.rb.Funny, I was struggling with the exact same problem just now with the Sybase adapter. Glad to hear I''m not losing my noodles. (c:> In Oracle, the adapter is able to detect the datatype, and returns > back the "right" type, rather than just strings. I''m assuming that > mysql just treats these as strings?That was my guess too. It does try to typecast the value to int, but not the key: def type_cast_calculated_value(value, column, operation) operation = operation.to_s.downcase case operation when ''count'' then value.to_i when ''avg'' then value.to_f else column ? column.type_cast(value) : value end end> If somebody (Rick?) can confirm I understand the issue properly, > I''ll make the unit tests pass for Oracle by hacking the tests if > the current adapter is Oracle.Well, it''s a problem for Sybase too, so it''d be nice to fix it for all cases. Maybe by normalizing the key? I noticed that if I added to_s in execute_grouped_calculation(), all those tests passed (but caused two other tests to fail): - key = associated ? key_records[row[group_alias].to_i] : row[group_alias] + key = associated ? key_records[row[group_alias].to_i] : row[group_alias].to_s Gotta be a more delicate fix for it, tho. John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net
> Well, it''s a problem for Sybase too, so it''d be nice to fix it for all > cases. Maybe by normalizing the key? I noticed that if I added to_s in > execute_grouped_calculation(), all those tests passed (but caused two > other tests to fail):Yeah, except that seems backwards -- the key actually is an int, would be nice if we could leave it that way. Actually forcing it to a string in calculations seems odd. I was also thinking that it could be resolved by returning something like OrderedHashWithIndifferentAccess, and having the unit tests test using the symbols.
* Michael Schoen (schoenm@earthlink.net) [060228 20:03]:> Yeah, except that seems backwards -- the key actually is an int, would > be nice if we could leave it that way. Actually forcing it to a string > in calculations seems odd. > > I was also thinking that it could be resolved by returning something > like OrderedHashWithIndifferentAccess, and having the unit tests test > using the symbols.I haven''t had a chance to run the new calculations code against our Oracle install yet, but I''d believe that the Oracle adapter+driver''s "smart" typecasting is at work. It seems like client code (which test code also is) should be oblivious to the underlying database adapter -- so far the indifferent access technique seems like the most straightforward way to get uniform behavior to me. Rick -- http://www.rickbradley.com MUPRN: 716 | absurd and annoying random email haiku | EULA everyone clicks through | without reading now).
On 2/28/06, Rick Bradley <rick@rickbradley.com> wrote:> * Michael Schoen (schoenm@earthlink.net) [060228 20:03]: > > Yeah, except that seems backwards -- the key actually is an int, would > > be nice if we could leave it that way. Actually forcing it to a string > > in calculations seems odd. > > > > I was also thinking that it could be resolved by returning something > > like OrderedHashWithIndifferentAccess, and having the unit tests test > > using the symbols. > > I haven''t had a chance to run the new calculations code against our > Oracle install yet, but I''d believe that the Oracle adapter+driver''s > "smart" typecasting is at work. > > It seems like client code (which test code also is) should be oblivious > to the underlying database adapter -- so far the indifferent access > technique seems like the most straightforward way to get uniform > behavior to me. > > Rick > -- > http://www.rickbradley.com MUPRN: 716 > | absurd and annoying > random email haiku | EULA everyone clicks through > | without reading now).Hi everyone, thanks for the heads-up. Try this patch: http://dev.rubyonrails.org/attachment/ticket/4016/calc.2.diff -- Rick Olson http://techno-weenie.net
> Hi everyone, thanks for the heads-up. Try this patch: > > http://dev.rubyonrails.org/attachment/ticket/4016/calc.2.diffHey Rick, I tried that patch against the Sybase adapter and it fixes things perfectly. Thumbs up on my side for a commit. Thanks for the quick turnaround! John