Rich Cox
2007-Oct-15 07:40 UTC
Rails AR/SQLServer Unit Test: [7909] failed (getting worse)
"bitsweat" has kicked AR/SQLServer while it was down...
http://dev.rubyonrails.org/changeset/7909
------------------------------------------------------------------------
r7909 | bitsweat | 2007-10-15 00:33:53 -0700 (Mon, 15 Oct 2007) | 2 lines
Test that change_column quotes column names. Closes #9537 [lawrence]
------------------------------------------------------------------------
U activerecord\test\migration_test.rb
Updated to revision 7909.
1) Failure:
test_save_for_record_with_only_primary_key(BasicsTest)
[./test/base_test.rb:197:in
`test_save_for_record_with_only_primary_key''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run'']:
Exception raised:
Class: <ActiveRecord::StatementInvalid>
Message: <"DBI::DatabaseError: Execute\n OLE error code:80040E14 in
Microsoft OLE DB Provider for SQL Server\n An explicit value for the
identity column in table ''minimalistics'' can only be specified
when a column list is used and IDENTITY_INSERT is ON.\n HRESULT error
code:0x80020009\n Exception occurred.: INSERT INTO minimalistics
VALUES(DEFAULT)">
---Backtrace---
./test/../lib/active_record/connection_adapters/abstract_adapter.rb:137:in
`log''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:337:in
`execute_without_counting''
./test/abstract_unit.rb:70:in `execute''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:155:in
`insert_sql''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:318:in
`insert_sql''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:44:in
`insert_without_query_dirty''
./test/../lib/active_record/connection_adapters/abstract/query_cache.rb:19:in
`insert''
./test/../lib/active_record/base.rb:2013:in `create_without_callbacks''
./test/../lib/active_record/callbacks.rb:226:in
`create_without_timestamps''
./test/../lib/active_record/timestamp.rb:29:in `create''
./test/../lib/active_record/base.rb:1979:in
`create_or_update_without_callbacks''
./test/../lib/active_record/callbacks.rb:213:in `create_or_update''
./test/../lib/active_record/base.rb:1731:in `save_without_validation''
./test/../lib/active_record/validations.rb:877:in
`save_without_transactions''
./test/../lib/active_record/transactions.rb:105:in `save''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:66:in
`transaction''
./test/../lib/active_record/transactions.rb:77:in `transaction''
./test/../lib/active_record/transactions.rb:97:in `transaction''
./test/../lib/active_record/transactions.rb:105:in `save''
./test/../lib/active_record/transactions.rb:117:in
`rollback_active_record_state!''
./test/../lib/active_record/transactions.rb:105:in `save''
./test/base_test.rb:197:in `test_save_for_record_with_only_primary_key''
./test/base_test.rb:197:in `test_save_for_record_with_only_primary_key''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run''
---------------
2) Failure:
test_save_for_record_with_only_primary_key_that_is_provided(BasicsTest)
[./test/base_test.rb:201:in
`test_save_for_record_with_only_primary_key_that_is_provided''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run'']:
Exception raised:
Class: <ActiveRecord::StatementInvalid>
Message: <"DBI::DatabaseError: Execute\n OLE error code:80040E14 in
Microsoft OLE DB Provider for SQL Server\n An explicit value for the
identity column in table ''minimalistics'' can only be specified
when a column list is used and IDENTITY_INSERT is ON.\n HRESULT error
code:0x80020009\n Exception occurred.: INSERT INTO minimalistics
VALUES(DEFAULT)">
---Backtrace---
./test/../lib/active_record/connection_adapters/abstract_adapter.rb:137:in
`log''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:337:in
`execute_without_counting''
./test/abstract_unit.rb:70:in `execute''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:155:in
`insert_sql''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:318:in
`insert_sql''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:44:in
`insert_without_query_dirty''
./test/../lib/active_record/connection_adapters/abstract/query_cache.rb:19:in
`insert''
./test/../lib/active_record/base.rb:2013:in `create_without_callbacks''
./test/../lib/active_record/callbacks.rb:226:in
`create_without_timestamps''
./test/../lib/active_record/timestamp.rb:29:in `create''
./test/../lib/active_record/base.rb:1979:in
`create_or_update_without_callbacks''
./test/../lib/active_record/callbacks.rb:213:in `create_or_update''
./test/../lib/active_record/base.rb:1737:in `save_without_validation!''
./test/../lib/active_record/validations.rb:887:in
`save_without_transactions!''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:66:in
`transaction''
./test/../lib/active_record/transactions.rb:77:in `transaction''
./test/../lib/active_record/transactions.rb:97:in `transaction''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/../lib/active_record/transactions.rb:117:in
`rollback_active_record_state!''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/../lib/active_record/validations.rb:852:in `create!''
./test/base_test.rb:201:in
`test_save_for_record_with_only_primary_key_that_is_provided''
./test/base_test.rb:201:in
`test_save_for_record_with_only_primary_key_that_is_provided''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run''
---------------
3) Error:
test_scoped_find_limit_offset_including_has_many_association(BasicsTest):
ActiveRecord::StatementInvalid: DBI::DatabaseError: Execute
OLE error code:80040E14 in Microsoft OLE DB Provider for SQL Server
Ambiguous column name ''id''.
HRESULT error code:0x80020009
Exception occurred.: SELECT topics.[id] AS t0_r0, topics.[title] AS t0_r1,
topics.[author_name] AS t0_r2, topics.[author_email_address] AS t0_r3,
topics.[written_on] AS t0_r4, topics.[bonus_time] AS t0_r5, topics.[last_read]
AS t0_r6, topics.[content] AS t0_r7, topics.[approved] AS t0_r8,
topics.[replies_count] AS t0_r9, topics.[parent_id] AS t0_r10, topics.[type] AS
t0_r11, replies_topics.[id] AS t1_r0, replies_topics.[title] AS t1_r1,
replies_topics.[author_name] AS t1_r2, replies_topics.[author_email_address] AS
t1_r3, replies_topics.[written_on] AS t1_r4, replies_topics.[bonus_time] AS
t1_r5, replies_topics.[last_read] AS t1_r6, replies_topics.[content] AS t1_r7,
replies_topics.[approved] AS t1_r8, replies_topics.[replies_count] AS t1_r9,
replies_topics.[parent_id] AS t1_r10, rep
lies_topics.[type] AS t1_r11 FROM topics LEFT OUTER JOIN topics replies_topics
ON replies_topics.parent_id = topics.id AND replies_topics.[type] =
''Reply'' WHERE topics.id IN (2) ORDER BY id
./test/../lib/active_record/connection_adapters/abstract_adapter.rb:137:in
`log''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:337:in
`execute_without_counting''
./test/abstract_unit.rb:70:in `execute''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:533:in
`select''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:7:in
`select_all_without_query_cache''
./test/../lib/active_record/connection_adapters/abstract/query_cache.rb:55:in
`select_all''
./test/../lib/active_record/associations.rb:1237:in
`select_all_rows''
./test/../lib/active_record/associations.rb:1119:in
`find_with_associations''
./test/../lib/active_record/associations.rb:1117:in `catch''
./test/../lib/active_record/associations.rb:1117:in
`find_with_associations''
./test/../lib/active_record/base.rb:1009:in `find_every''
./test/../lib/active_record/base.rb:436:in `find''
./test/base_test.rb:1487:in
`test_scoped_find_limit_offset_including_has_many_association''
./test/../lib/active_record/base.rb:1464:in `with_scope''
./test/base_test.rb:1486:in
`test_scoped_find_limit_offset_including_has_many_association''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run''
4) Error:
test_saves_both_date_and_time(DateTimeTest):
ArgumentError: argument out of range
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:106:in
`mktime''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:106:in
`cast_to_datetime''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:79:in
`type_cast''
./test/../lib/active_record/attribute_methods.rb:218:in
`read_attribute''
./test/../lib/active_record/base.rb:2207:in `send''
./test/../lib/active_record/base.rb:2207:in `clone_attribute_value''
./test/../lib/active_record/base.rb:2201:in `clone_attributes''
./test/../lib/active_record/attribute_methods.rb:160:in `inject''
./test/../lib/active_record/base.rb:2200:in `each''
./test/../lib/active_record/base.rb:2200:in `inject''
./test/../lib/active_record/base.rb:2200:in `clone_attributes''
./test/../lib/active_record/base.rb:1870:in `attributes''
./test/../lib/active_record/base.rb:2084:in
`attributes_with_quotes''
./test/../lib/active_record/base.rb:2003:in
`create_without_callbacks''
./test/../lib/active_record/callbacks.rb:226:in
`create_without_timestamps''
./test/../lib/active_record/timestamp.rb:29:in `create''
./test/../lib/active_record/base.rb:1979:in
`create_or_update_without_callbacks''
./test/../lib/active_record/callbacks.rb:213:in `create_or_update''
./test/../lib/active_record/base.rb:1737:in
`save_without_validation!''
./test/../lib/active_record/validations.rb:887:in
`save_without_transactions!''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:66:in
`transaction''
./test/../lib/active_record/transactions.rb:77:in `transaction''
./test/../lib/active_record/transactions.rb:97:in `transaction''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/../lib/active_record/transactions.rb:117:in
`rollback_active_record_state!''
./test/../lib/active_record/transactions.rb:109:in `save!''
./test/date_time_test.rb:11:in `test_saves_both_date_and_time''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run''
5) Error:
test_eager_association_loading_with_explicit_join(EagerAssociationTest):
ActiveRecord::StatementInvalid: DBI::DatabaseError: Execute
OLE error code:80040E14 in Microsoft OLE DB Provider for SQL Server
ORDER BY items must appear in the select list if SELECT DISTINCT is
specified.
HRESULT error code:0x80020009
Exception occurred.: SELECT DISTINCT TOP 1 posts.id FROM posts LEFT OUTER
JOIN comments ON comments.post_id = posts.id INNER JOIN authors ON
posts.author_id = authors.id AND authors.name = ''Mary'' ORDER
BY author_id
./test/../lib/active_record/connection_adapters/abstract_adapter.rb:137:in
`log''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:337:in
`execute_without_counting''
./test/abstract_unit.rb:70:in `execute''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:533:in
`select''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:7:in
`select_all_without_query_cache''
./test/../lib/active_record/connection_adapters/abstract/query_cache.rb:55:in
`select_all''
./test/../lib/active_record/associations.rb:1271:in
`select_limited_ids_list''
./test/../lib/active_record/associations.rb:1261:in
`add_limited_ids_condition!''
./test/../lib/active_record/associations.rb:1250:in
`construct_finder_sql_with_included_associations''
./test/../lib/active_record/associations.rb:1238:in
`select_all_rows''
./test/../lib/active_record/associations.rb:1119:in
`find_with_associations''
./test/../lib/active_record/associations.rb:1117:in `catch''
./test/../lib/active_record/associations.rb:1117:in
`find_with_associations''
./test/../lib/active_record/base.rb:1009:in `find_every''
./test/../lib/active_record/base.rb:436:in `find''
./test/associations/eager_test.rb:107:in
`test_eager_association_loading_with_explicit_join''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`__send__''
c:/ruby/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in
`run''
6) Error:
test_limited_eager_with_multiple_order_columns(EagerAssociationTest):
ActiveRecord::StatementInvalid: DBI::DatabaseError: Execute
OLE error code:80040E14 in Microsoft OLE DB Provider for SQL Server
ORDER BY items must appear in the select list if SELECT DISTINCT is
specified.
HRESULT error code:0x80020009
Exception occurred.: SELECT * FROM (SELECT TOP 2 * FROM (SELECT DISTINCT
TOP 3 posts.id FROM posts LEFT OUTER JOIN authors ON authors.id =
posts.author_id LEFT OUTER JOIN comments ON comments.post_id = posts.id WHERE
(authors.name = ''David'') ORDER BY UPPER(posts.title),
posts.id) AS tmp1 ORDER BY title DESC, id DESC) AS tmp2 ORDER BY title, id
./test/../lib/active_record/connection_adapters/abstract_adapter.rb:137:in
`log''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:337:in
`execute_without_counting''
./test/abstract_unit.rb:70:in `execute''
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-sqlserver-adapter-1.0.0/lib/active_record/connection_adapters/sqlserver_adapter.rb:533:in
`select''
./test/../lib/active_record/connection_adapters/abstract/database_statements.rb:7:in
`select_all_without_query_cache''
./test/../lib/active_record/connection_adapters/abstract/query_cache.rb:55:in
`select_all''
./test/../lib/active_record/associations.rb:1271:in
`select_limited_ids_list''
./test/../lib/active_record/associations.rb:1261:in
`add_limited_ids_condition!''
./test/../lib/active_record/associations.rb:1250:in
`construct_finder_sql_with_included_associations''
./test/../lib/active_record/associations.rb:1238:in
`select_all_rows''
./test/../lib/active_record/asso
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
Hi All, Is there a specific reason why all those scripts in activerecord/test/fixtures/db_definitions exist instead of one database independent migration file? Imo the ability or inability to get the migration file correctly imported in the database of your choice is already a test. Regards, Lawrence --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/15/07, Lawrence Pit <lawrence.pit@gmail.com> wrote:> > Hi All, > > Is there a specific reason why all those scripts in > activerecord/test/fixtures/db_definitions exist instead of one database > independent migration file? >+1 for schema in Ruby format ... I don''t think that tests use db features that AR::Migrations don''t support currently. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 15, 2007, at 7:14 , Mislav Marohnić wrote:> +1 for schema in Ruby format ... I don''t think that tests use db > features > that AR::Migrations don''t support currently.As you can use execute in migrations, there should be the possibility of including tests for database-specific implementation. I don''t know if there are any such tests right now, but unless the current situation is actually broken, I don''t see a reason why to fix it. Michael Glaesemann grzm seespotcode net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/15/07, Michael Glaesemann <grzm@seespotcode.net> wrote:> > > I don''t know > if there are any such tests right now, but unless the current > situation is actually broken, I don''t see a reason why to fix it.The current situation is not broken, but difficult to maintain as schema changes require multiple files to be updated with different syntaxes. AR::Migrations were created to solve exactly this problem, and I think they''re powerful enough to set up the database for testing. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/15/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 10/15/07, Michael Glaesemann <grzm@seespotcode.net> wrote: > > > > I don't know > > if there are any such tests right now, but unless the current > > situation is actually broken, I don't see a reason why to fix it. > > The current situation is not broken, but difficult to maintain as schema > changes require multiple files to be updated with different syntaxes. > AR::Migrations were created to solve exactly this problem, and I think > they're powerful enough to set up the database for testing.By the time migrations were added, there were a lot of tests using those old schema files. Since then, all future additions should have been made in the ruby schema files. David has asked several times for someone to clean that up and convert to ruby schema files, but it is a larger job than it may initially look. Does someone want to give it a shot? -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 15, 7:53 am, "Rick Olson" <technowee...@gmail.com> wrote:> On 10/15/07, Mislav Marohni <mislav.maroh...@gmail.com> wrote: > > > On 10/15/07, Michael Glaesemann <g...@seespotcode.net> wrote: > > > > I don''t know > > > if there are any such tests right now, but unless the current > > > situation is actually broken, I don''t see a reason why to fix it. > > > The current situation is not broken, but difficult to maintain as schema > > changes require multiple files to be updated with different syntaxes. > > AR::Migrations were created to solve exactly this problem, and I think > > they''re powerful enough to set up the database for testing. > > By the time migrations were added, there were a lot of tests using > those old schema files. Since then, all future additions should have > been made in the ruby schema files. David has asked several times for > someone to clean that up and convert to ruby schema files, but it is a > larger job than it may initially look. Does someone want to give it a > shot? > > -- > Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephistoblog.comAll those sql files under db_definitions need to be moved to schema.rb, right? Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a time, and initially just add a condition to check for the adapter in schema.rb. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/15/07, Lawrence Pit <lawrence.pit@gmail.com> wrote:> Is there a specific reason why all those scripts in > activerecord/test/fixtures/db_definitions exist instead of > one database independent migration file?Largely because they were created before migrations and the schema dumper. There are also some db definitions that can''t be done in schema.rb.> Imo the ability or inability to get the migration file correctly imported > in the database of your choice is already a test.All new additions use schema.rb in the same dir. jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Other issues include: 1) Inconsistencies between different databases: for example topics.content is of type VARCHAR(255) in SQL Server but of type TEXT in MySQL. 2) If any .sql files should exist, then they should exist within the plugin adapter, not within rails core. I''ll have a shot at transforming this into a migrations file. I''ll attempt this first for SQL Server only, this should not affect core. If that works we can see if/how this can used by all the other adapters. > There are also some db definitions that can''t be done in schema.rb. Ok, I see those. We should be able to work around ''m.. I''ll have a look. Regards, Lawrence> On 10/15/07, *Michael Glaesemann* <grzm@seespotcode.net > <mailto:grzm@seespotcode.net>> wrote: > > > I don''t know > if there are any such tests right now, but unless the current > situation is actually broken, I don''t see a reason why to fix it. > > > The current situation is not broken, but difficult to maintain as > schema changes require multiple files to be updated with different > syntaxes. AR::Migrations were created to solve exactly this problem, > and I think they''re powerful enough to set up the database for testing. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> All those sql files under db_definitions need to be moved to > schema.rb, right? > > Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a > time, and initially just add a condition to check for the adapter in > schema.rb.I think that''d be fine. If it''s a temporary condition put in place until the transition is done, just keep it commented so it''s obvious what''s going on. Smaller patches are easier to deal with. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I''ve encountered some problems with simply moving the sql files to schema.rb. The sql files that end with 2 need to connect to activerecord_unittest2. Moving it to schema.rb would result to having the courses table created in activerecord_unittest1. Is it OK to create a schema2.rb to be used for the courses table? That is, in AAACreateTablesTest#test_drop_and_create_courses_table, we can read schema2.rb in the same way that schema.rb is read in AAACreateTablesTest#test_load_schema. On Oct 16, 4:57 am, "Rick Olson" <technowee...@gmail.com> wrote:> > All those sql files under db_definitions need to be moved to > > schema.rb, right? > > > Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a > > time, and initially just add a condition to check for the adapter in > > schema.rb. > > I think that''d be fine. If it''s a temporary condition put in place > until the transition is done, just keep it commented so it''s obvious > what''s going on. Smaller patches are easier to deal with. > > -- > Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephistoblog.com--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
See patch http://dev.rubyonrails.org/ticket/9897 Cheers, Lawrence> I''ve encountered some problems with simply moving the sql files to > schema.rb. The sql files that end with 2 need to connect to > activerecord_unittest2. Moving it to schema.rb would result to having > the courses table created in activerecord_unittest1. > > Is it OK to create a schema2.rb to be used for the courses table? That > is, in AAACreateTablesTest#test_drop_and_create_courses_table, we can > read schema2.rb in the same way that schema.rb is read in > AAACreateTablesTest#test_load_schema. > > On Oct 16, 4:57 am, "Rick Olson" <technowee...@gmail.com> wrote: > >>> All those sql files under db_definitions need to be moved to >>> schema.rb, right? >>> >>> Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a >>> time, and initially just add a condition to check for the adapter in >>> schema.rb. >>> >> I think that''d be fine. If it''s a temporary condition put in place >> until the transition is done, just keep it commented so it''s obvious >> what''s going on. Smaller patches are easier to deal with. >> >> -- >> Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephistoblog.com >> > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for the link. I kinda liked the approach of doing this 1 db adapter at a time since I don''t want to send a patch that affects other databases that I can''t test locally. Anyway, I''ll submit a patch soon as I''m almost done moving db/definitions/mysql*.sql to schema*.rb. I''ll keep a close watch on your ticket''s progress. I think I''ll just have 2 patches in my new ticket, 1 for mysql.sql and the other for mysql2.sql so that in case your patch is accepted, we can just ignore the mysql2 patch. What do you think? Btw, is anyone also working on a patch for MySQL? I''m just checking coz I''ll stop my work on this if anyone already is. I plan to do this for PostgeSQL after. On Oct 16, 4:56 pm, Lawrence Pit <lawrence....@gmail.com> wrote:> See patchhttp://dev.rubyonrails.org/ticket/9897 > > Cheers, > Lawrence > > > I''ve encountered some problems with simply moving the sql files to > > schema.rb. The sql files that end with 2 need to connect to > > activerecord_unittest2. Moving it to schema.rb would result to having > > the courses table created in activerecord_unittest1. > > > Is it OK to create a schema2.rb to be used for the courses table? That > > is, in AAACreateTablesTest#test_drop_and_create_courses_table, we can > > read schema2.rb in the same way that schema.rb is read in > > AAACreateTablesTest#test_load_schema. > > > On Oct 16, 4:57 am, "Rick Olson" <technowee...@gmail.com> wrote: > > >>> All those sql files under db_definitions need to be moved to > >>> schema.rb, right? > > >>> Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a > >>> time, and initially just add a condition to check for the adapter in > >>> schema.rb. > > >> I think that''d be fine. If it''s a temporary condition put in place > >> until the transition is done, just keep it commented so it''s obvious > >> what''s going on. Smaller patches are easier to deal with. > > >> -- > >> Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephist...--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Added http://dev.rubyonrails.org/ticket/9899 FYI On Oct 16, 6:30 pm, mikong <michaelgal...@gmail.com> wrote:> Thanks for the link. I kinda liked the approach of doing this 1 db > adapter at a time since I don''t want to send a patch that affects > other databases that I can''t test locally. Anyway, I''ll submit a patch > soon as I''m almost done moving db/definitions/mysql*.sql to > schema*.rb. I''ll keep a close watch on your ticket''s progress. I think > I''ll just have 2 patches in my new ticket, 1 for mysql.sql and the > other for mysql2.sql so that in case your patch is accepted, we can > just ignore the mysql2 patch. What do you think? > > Btw, is anyone also working on a patch for MySQL? I''m just checking > coz I''ll stop my work on this if anyone already is. I plan to do this > for PostgeSQL after. > > On Oct 16, 4:56 pm, Lawrence Pit <lawrence....@gmail.com> wrote: > > > See patchhttp://dev.rubyonrails.org/ticket/9897 > > > Cheers, > > Lawrence > > > > I''ve encountered some problems with simply moving the sql files to > > > schema.rb. The sql files that end with 2 need to connect to > > > activerecord_unittest2. Moving it to schema.rb would result to having > > > the courses table created in activerecord_unittest1. > > > > Is it OK to create a schema2.rb to be used for the courses table? That > > > is, in AAACreateTablesTest#test_drop_and_create_courses_table, we can > > > read schema2.rb in the same way that schema.rb is read in > > > AAACreateTablesTest#test_load_schema. > > > > On Oct 16, 4:57 am, "Rick Olson" <technowee...@gmail.com> wrote: > > > >>> All those sql files under db_definitions need to be moved to > > >>> schema.rb, right? > > > >>> Does it have to be in 1 patch? Maybe we can do this 1 db adapter at a > > >>> time, and initially just add a condition to check for the adapter in > > >>> schema.rb. > > > >> I think that''d be fine. If it''s a temporary condition put in place > > >> until the transition is done, just keep it commented so it''s obvious > > >> what''s going on. Smaller patches are easier to deal with. > > > >> -- > > >> Rick Olsonhttp://lighthouseapp.comhttp://weblog.techno-weenie.nethttp://mephist...--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> since I don''t want to send a patch that affects other databasesNote that when one adds a test, this already affects all databases. I''m pretty sure tests and patches get into core without being tested on all or at least a significant number of databases. So this is really a general issue, not just for this little project. The problem with doing this one adapter at a time is that if you created a schema.rb based on mysql.sql and someone else creates a schema.rb based on say oracle.sql or postgresql.sql, you''d end up with significant different schema.rb files. So whose schema.rb is going to end up in core? I had also moved all mysql.sql statement into a schema.rb (except for tables subscribers, fk_test_has_pk and fk_test_has_fk, for which no migrations equivalent exists). Works fine for mysql, but then shows quite a few regressions on quite a few other databases. For example, posts.body is of type text in mysql, so you''d think t.text :body would be the answer, unfortunately the tests do a search via that field which is not an allowed operation on e.g. SQL Server (which is why in the sql stament SQL Server defines the field as varchar(4096) instead of text; same for Oracle, Sybase and I suspect Firebird and DB2 as well). I guess the one db adapter at a time approach works, but imo we need to do this sequentially. So if you create a patch for mysql, then we all should first get behind that one and get it into core before we move on to the next database adapter. Lawrence> Thanks for the link. I kinda liked the approach of doing this 1 db > adapter at a time since I don''t want to send a patch that affects > other databases that I can''t test locally. Anyway, I''ll submit a patch > soon as I''m almost done moving db/definitions/mysql*.sql to > schema*.rb. I''ll keep a close watch on your ticket''s progress. I think > I''ll just have 2 patches in my new ticket, 1 for mysql.sql and the > other for mysql2.sql so that in case your patch is accepted, we can > just ignore the mysql2 patch. What do you think? > > Btw, is anyone also working on a patch for MySQL? I''m just checking > coz I''ll stop my work on this if anyone already is. I plan to do this > for PostgeSQL after. > > On Oct 16, 4:56 pm, Lawrence Pit <lawrence....@gmail.com> wrote: > >> See patchhttp://dev.rubyonrails.org/ticket/9897 >> >> Cheers, >> Lawrence >>--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> > since I don''t want to send a patch that affects other databases > > Note that when one adds a test, this already affects all databases. I''m > pretty sure tests and patches get into core without being tested on all > or at least a significant number of databases. So this is really a > general issue, not just for this little project.I actually ended up changing AAACreateTablesTest and I realized what you mean (that I''ve just added a patch that affects other databases), so I guess that wasn''t the right argument. For my patch though, it surely won''t work for other databases without the condition that I added to check if the adapter is MySQL. I guess what I meant is that since I''m not very familiar with the other database adapters, I''m not capable of creating a patch for this particular issue that would work for all. So I was hoping we could do this with the help of other contributors familiar with the other databases. Btw, instead of creating 2 patches as I''ve mentioned before, I didn''t create the patch for removing mysql2.sql and mysql2.drop.sql. Instead, I just referenced your ticket so there''s no wasted effort.> I guess the one db adapter at a time approach works, but imo we need to > do this sequentially. So if you create a patch for mysql, then we all > should first get behind that one and get it into core before we move on > to the next database adapter.It would be great if we could do this sequentially. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I''m testing your patch. Works fine for MySQL, of course ;-) Nice solution for table subscribers. While currently schema.rb begins with a line to test that the adapter is MySQL, the end goal is to remove that condition. So all databases would use the exact same migrations code. Take e.g. table :tasks. It defines the date fields as not null with a default. However, all other database sql files define the fields as nullable and no default. If we accept this patch, then for the next db adapter this would need to change. I.e.: it would affect all adapters that so far had switched to migrations. Other things include: - Remove :options => ''TYPE=InnoDB DEFAULT CHARSET=utf8''. It will then work for all databases, and still works for MySQL as well (if you have created your database using charset UTF8) - Explicitly define :scale => 0 for :numeric_data.world_population and my_house_population - We can, for now, change all columns of type :text to type :string. It should then work for other databases as well. However, it then does add one failing test for MySQL, but that is a test specific to MySQL only (i.e., modify the test to use a new table with a column of type :text). - The statement to create the foreign key should probably go into a seperate file for use by MySQL only. I.e., some statements will stay to be adapter specific. Doing the above I got it reasonably well working for SQL Server as well. :-) Generally I would have prefered the sexy migrations syntax, but that''s a different issue :) And some more: - You forgot to include the patch for the courses table. ;) - In the rakefile, target mysql:build_databases, remove the statements that would import the sql files. Btw, I am giving a +1 to the patch in its current state, as it does work for MySQL, which was the goal for this patch. The above can be modified later. Happy to have this train moving :-) Cheers, Lawrence>> > since I don''t want to send a patch that affects other databases >> >> Note that when one adds a test, this already affects all databases. I''m >> pretty sure tests and patches get into core without being tested on all >> or at least a significant number of databases. So this is really a >> general issue, not just for this little project. >> > > I actually ended up changing AAACreateTablesTest and I realized what > you mean (that I''ve just added a patch that affects other databases), > so I guess that wasn''t the right argument. For my patch though, it > surely won''t work for other databases without the condition that I > added to check if the adapter is MySQL. I guess what I meant is that > since I''m not very familiar with the other database adapters, I''m not > capable of creating a patch for this particular issue that would work > for all. So I was hoping we could do this with the help of other > contributors familiar with the other databases. > > Btw, instead of creating 2 patches as I''ve mentioned before, I didn''t > create the patch for removing mysql2.sql and mysql2.drop.sql. Instead, > I just referenced your ticket so there''s no wasted effort. > > >> I guess the one db adapter at a time approach works, but imo we need to >> do this sequentially. So if you create a patch for mysql, then we all >> should first get behind that one and get it into core before we move on >> to the next database adapter. >> > > It would be great if we could do this sequentially. > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Exactly the kind of feedback I was hoping for. :) I''ll apply most if not all of your comments. I''ll have a closer look later after work, and expect an updated patch in maybe 10 hours. Thanks a lot! On Oct 16, 10:23 pm, Lawrence Pit <lawrence....@gmail.com> wrote:> I''m testing your patch. Works fine for MySQL, of course ;-) > > Nice solution for table subscribers. > > While currently schema.rb begins with a line to test that the adapter is > MySQL, the end goal is to remove that condition. So all databases would > use the exact same migrations code. > > Take e.g. table :tasks. It defines the date fields as not null with a > default. However, all other database sql files define the fields as > nullable and no default. If we accept this patch, then for the next db > adapter this would need to change. I.e.: it would affect all adapters > that so far had switched to migrations. > > Other things include: > > - Remove :options => ''TYPE=InnoDB DEFAULT CHARSET=utf8''. It will then > work for all databases, and still works for MySQL as well (if you have > created your database using charset UTF8) > > - Explicitly define :scale => 0 for :numeric_data.world_population and > my_house_population > > - We can, for now, change all columns of type :text to type :string. It > should then work for other databases as well. However, it then does add > one failing test for MySQL, but that is a test specific to MySQL only > (i.e., modify the test to use a new table with a column of type :text). > > - The statement to create the foreign key should probably go into a > seperate file for use by MySQL only. I.e., some statements will stay to > be adapter specific. > > Doing the above I got it reasonably well working for SQL Server as well. :-) > > Generally I would have prefered the sexy migrations syntax, but that''s a > different issue :) > > And some more: > > - You forgot to include the patch for the courses table. ;) > > - In the rakefile, target mysql:build_databases, remove the statements > that would import the sql files. > > Btw, I am giving a +1 to the patch in its current state, as it does work > for MySQL, which was the goal for this patch. The above can be modified > later. > > Happy to have this train moving :-) > > Cheers, > Lawrence > > >> > since I don''t want to send a patch that affects other databases > > >> Note that when one adds a test, this already affects all databases. I''m > >> pretty sure tests and patches get into core without being tested on all > >> or at least a significant number of databases. So this is really a > >> general issue, not just for this little project. > > > I actually ended up changing AAACreateTablesTest and I realized what > > you mean (that I''ve just added a patch that affects other databases), > > so I guess that wasn''t the right argument. For my patch though, it > > surely won''t work for other databases without the condition that I > > added to check if the adapter is MySQL. I guess what I meant is that > > since I''m not very familiar with the other database adapters, I''m not > > capable of creating a patch for this particular issue that would work > > for all. So I was hoping we could do this with the help of other > > contributors familiar with the other databases. > > > Btw, instead of creating 2 patches as I''ve mentioned before, I didn''t > > create the patch for removing mysql2.sql and mysql2.drop.sql. Instead, > > I just referenced your ticket so there''s no wasted effort. > > >> I guess the one db adapter at a time approach works, but imo we need to > >> do this sequentially. So if you create a patch for mysql, then we all > >> should first get behind that one and get it into core before we move on > >> to the next database adapter. > > > It would be great if we could do this sequentially.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
New patches have been added to the ticket. FYI http://dev.rubyonrails.org/ticket/9899 On Oct 16, 10:42 pm, mikong <michaelgal...@gmail.com> wrote:> Exactly the kind of feedback I was hoping for. :) > > I''ll apply most if not all of your comments. I''ll have a closer look > later after work, and expect an updated patch in maybe 10 hours. > > Thanks a lot! > > On Oct 16, 10:23 pm, Lawrence Pit <lawrence....@gmail.com> wrote: > > > I''m testing your patch. Works fine for MySQL, of course ;-) > > > Nice solution for table subscribers. > > > While currently schema.rb begins with a line to test that the adapter is > > MySQL, the end goal is to remove that condition. So all databases would > > use the exact same migrations code. > > > Take e.g. table :tasks. It defines the date fields as not null with a > > default. However, all other database sql files define the fields as > > nullable and no default. If we accept this patch, then for the next db > > adapter this would need to change. I.e.: it would affect all adapters > > that so far had switched to migrations. > > > Other things include: > > > - Remove :options => ''TYPE=InnoDB DEFAULT CHARSET=utf8''. It will then > > work for all databases, and still works for MySQL as well (if you have > > created your database using charset UTF8) > > > - Explicitly define :scale => 0 for :numeric_data.world_population and > > my_house_population > > > - We can, for now, change all columns of type :text to type :string. It > > should then work for other databases as well. However, it then does add > > one failing test for MySQL, but that is a test specific to MySQL only > > (i.e., modify the test to use a new table with a column of type :text). > > > - The statement to create the foreign key should probably go into a > > seperate file for use by MySQL only. I.e., some statements will stay to > > be adapter specific. > > > Doing the above I got it reasonably well working for SQL Server as well. :-) > > > Generally I would have prefered the sexy migrations syntax, but that''s a > > different issue :) > > > And some more: > > > - You forgot to include the patch for the courses table. ;) > > > - In the rakefile, target mysql:build_databases, remove the statements > > that would import the sql files. > > > Btw, I am giving a +1 to the patch in its current state, as it does work > > for MySQL, which was the goal for this patch. The above can be modified > > later. > > > Happy to have this train moving :-) > > > Cheers, > > Lawrence > > > >> > since I don''t want to send a patch that affects other databases > > > >> Note that when one adds a test, this already affects all databases. I''m > > >> pretty sure tests and patches get into core without being tested on all > > >> or at least a significant number of databases. So this is really a > > >> general issue, not just for this little project. > > > > I actually ended up changing AAACreateTablesTest and I realized what > > > you mean (that I''ve just added a patch that affects other databases), > > > so I guess that wasn''t the right argument. For my patch though, it > > > surely won''t work for other databases without the condition that I > > > added to check if the adapter is MySQL. I guess what I meant is that > > > since I''m not very familiar with the other database adapters, I''m not > > > capable of creating a patch for this particular issue that would work > > > for all. So I was hoping we could do this with the help of other > > > contributors familiar with the other databases. > > > > Btw, instead of creating 2 patches as I''ve mentioned before, I didn''t > > > create the patch for removing mysql2.sql and mysql2.drop.sql. Instead, > > > I just referenced your ticket so there''s no wasted effort. > > > >> I guess the one db adapter at a time approach works, but imo we need to > > >> do this sequentially. So if you create a patch for mysql, then we all > > >> should first get behind that one and get it into core before we move on > > >> to the next database adapter. > > > > It would be great if we could do this sequentially.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi All, As a continuation to migrate more database adapters towards use of schema.rb instead of .sql files to create the test environment: http://dev.rubyonrails.org/ticket/9929 Need 2 more +s please. In case you wonder why the sqlite_adapter needs a change: if you keep it as it is today, then the .sql files create the topics table with column bonus_time of type "TIME". However, if you create the topics table via a migrations file, using "t.time bonus_time", then currently it will be created with type "DATETIME". Running the tests sqlite3 will then show these two failures: 1) Failure: test_attributes_on_dummy_time(BasicsTest) [test/base_test.rb:959]: <Sat Jan 01 05:42:00 +1100 2000> expected but was <nil>. 2) Failure: test_utc_as_time_zone(BasicsTest) [test/base_test.rb:688]: <Sat Jan 01 05:42:00 UTC 2000> expected but was <nil>. This is because now with type "DATETIME", in schema_definitions.rb method type_cast(value) the :datetime type will go through method string_to_time. Instead, with type "TIME" is would go through the method string_to_dummy_time which is what it should do. After this change I propose the Postgresql adapter also starts using the schema.rb file. Cheers, Lawrence> New patches have been added to the ticket. FYI > > http://dev.rubyonrails.org/ticket/9899 > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---