This project is archived and is in readonly mode.
Process schema_migrations inserts individually during rake db:test:clone_structure.
Reported by Rick DeNatale | May 14th, 2008 @ 11:07 PM | in 2.1.1
I've spent a few hours today trying to move our rails app to 2.1RC1.
Our company has a significant number of migrations most of which were done using the enhanced_migrations plugin.
Rails 2.1 is using a similar idea of timestamping rather than sequencing migrations, but has some slight differences in the timestamps and the table used to store the migration info. enhanced_migrations uses a table named migrations_info, while 2.1 uses schema_migrations.
So our test rake task tried to re-run all of the migrations, since they didn't appear in the schema_migrations table.
Noticing that the new timestamps are human readable, e.g. yyyymmddhhmmss and the enhanced_migration timestamps are a 10-digit number so there should be an overlap. So we wrote a migration numbered 1 so that it would run first, which inserted each id column from the migrations_info table to a string and inserted the result as a row in the schema_migrations table.
This got us past the point where rake test was trying to re-run the migrations. However, and this is the real point of this note, when rake db:test:clone_structure got run, it failed because of a "SQL error" on INSERT schema_migrations (version) VALUES ('0'); which is valid SQL. After much head scratching, I figured out that it must actually because it was trying to run a long series of these inserts as on SQL query. I then tracked down where these inserts were coming from, which was development_structure.sql The db:test:clone structure basically reads this file, splits it into chunks delimited by empty lines, and plays each chunk against the test database. Most of these chunks are individual table definitions. But the last chunk is this set of inserts.
I tracked down the source of these lines in development_structure.sql to /activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb Suspecting that this was a problem with an overly long query I made a slight change (See attached patch) to insert an empty line between each insert statement. This does seem to have been the problem since with this change the rake db:test:clone_structure task succeeds.
I'm not sure where the limit is. In our case we have on the order of 500 migrations so on the order of 500 insert sql statements in the file.
Comments and changes to this ticket
-
Rick DeNatale May 15th, 2008 @ 08:23 PM
Actually, it might not just be a case of the chunk being too big, but that the execute method expects a single sql statement, which makes this a bit more critical.
-
Steven Soroka May 16th, 2008 @ 11:43 PM
I have the same problem and independently came up with the same patch. +1, please commit.
-
Michael Koziarski May 17th, 2008 @ 01:31 AM
- Milestone set to 2.1.1
- Assigned user set to Michael Koziarski
Could you reattach with git-format-patch output so we get the authorship etc correct. Also, in the commit message could you mention why this seemingly trivial thing makes a difference. This could easily get reverted if someone gets worried about the visual appearance of the dump
-
Steven Soroka May 17th, 2008 @ 06:48 AM
It makes a difference because SchemaStatements#dump_schema_information is inconsistent with db:clone_structure in databases.rake, and will create sql that db:clone_structure cannot load.
-
Repository May 17th, 2008 @ 07:51 AM
- State changed from new to resolved
(from [2183c220ada046993274ccdc6f1f86e9e8a3a5c6]) Make sure clone_structure can load the results of dump_schema_information
SchemaStatements#dump_schema_information joins inserts with a single \n, but is later split on \n\n, and fails when trying to execute all the inserts as a single sql statement.
Signed-off-by: Michael Koziarski
[#201 state:resolved]
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>