ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Generalize Journals migrations does too much (Bug #479)
| Status: | Closed | Start date: | 2011-06-16 |
|---|---|---|---|
| Priority: | High | Due date: | |
| Assignee: | Eric Davis |
% Done: | 0% |
| Category: | Journals / History | ||
| Target version: | 2.0.0 | ||
| Remote issue URL: | Affected version: | unstable |
Description
The GeneralizeJournals migration does too much and thus when it fails, the database is left in a state where it can't be recovered (due to schema changes that can't be wrapped in a transaction).
I'm going to split it up into multiple migrations so they can run separately. It will be some code duplication but it will be worth it if we don't have to debug a half-run migration in production.
Associated revisions
[#479] Split GeneralizeJournals into separate, incremental migrations
History
Updated by Eric Davis at 2011-06-17 04:55 pm
Split the single migration into 4 separate ones. 52b83da in release-v2.0.0
If someone has already successfully run the generalize_journals in production, they will need to insert a few values by hand so Rails doesn't try to re-run the migrations. This should work:
1insert into schema_migration VALUES ('20100714111652')
2insert into schema_migration VALUES ('20100714111653')
3insert into schema_migration VALUES ('20100714111654')
(20100714111651 is generalize_journals which should be there already)
- Status changed from Open to Closed
Updated by Ryan Briones at 2011-07-19 02:31 pm
Should be schema_migrations (plural)
INSERT INTO schema_migrations VALUES ('20100714111652');
INSERT INTO schema_migrations VALUES ('20100714111653');
INSERT INTO schema_migrations VALUES ('20100714111654');