1366 0 true 2010-01-30T08:48:26+00:00 1366 6 migrations-guide 19700 16213 published 2010-01-30T08:48:26+00:00 33958 Zach Hale Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 * All user facing features * Various rake tasks * Difference between sql and ruby schema format. When to use which. * All user facing features * Various rake tasks * Difference between sql and ruby schema format. When to use which. <div><ul> <li>All user facing features</li> <li>Various rake tasks</li> <li>Difference between sql and ruby schema format. When to use which.</li> </ul></div> 1366 0 * All user facing features * Various rake tasks * Difference between sql and ruby schema format. When to use which. <div><ul> <li>All user facing features</li> <li>Various rake tasks</li> <li>Difference between sql and ruby schema format. When to use which.</li> </ul></div> false 2008-09-04T14:47:12+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-04T14:47:12+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I'll have a stab at this <div><p>I'll have a stab at this</p></div> false 2008-09-05T15:09:45+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-05T15:09:48+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I'll give it a shot <div><p>I'll give it a shot</p></div> false 2008-09-05T22:28:11+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-05T22:28:13+01:00 11359 Tony Pitale Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Hey Tony, I'm trying to avoid 2 people working on the same guide. And Freddy has already started working on it. It'd be great if you can PM me at github or email me, in case you want to take a stab at another guide ( wether it's in the list or not ). Thanks. <div><p>Hey Tony,</p> <p>I'm trying to avoid 2 people working on the same guide. And Freddy has already started working on it. It'd be great if you can PM me at github or email me, in case you want to take a stab at another guide ( wether it's in the list or not ).</p> <p>Thanks.</p></div> false 2008-09-05T22:42:13+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-05T22:42:13+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 That works, PM sent. <div><p>That works, PM sent.</p></div> false 2008-09-05T22:50:42+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-05T22:50:47+01:00 11359 Tony Pitale Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I've pushed a first draft, feedback welcomed. <div><p>I've pushed a first draft, feedback welcomed.</p></div> false 2008-09-07T18:19:31+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-07T18:19:47+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 A few odds and ends, all pretty minor: * I'd like to see motivational text at the top, telling readers what they'll learn (as I did in the routing guide). * Nitpick: Do we have a standard for American vs. British spelling? Seems to me likely we should be using the former, so "organized" instead of "organised." * Style: (and at some point it would be nice to have a style editor to smooth out differences between guides): In general, "I" rather than "we" in technical writing ("we" as writer + reader is a false grouping, because they're not actually together in one place). * Passive voice: "ActiveRecord provides methods..." rather than "Methods are provided..." * Typo: You've got "t.references :attachement" in a code sample, should be "t.references :attachment" <div><p>A few odds and ends, all pretty minor:</p> <ul> <li>I'd like to see motivational text at the top, telling readers what they'll learn (as I did in the routing guide).</li> <li>Nitpick: Do we have a standard for American vs. British spelling? Seems to me likely we should be using the former, so "organized" instead of "organised."</li> <li>Style: (and at some point it would be nice to have a style editor to smooth out differences between guides): In general, "I" rather than "we" in technical writing ("we" as writer + reader is a false grouping, because they're not actually together in one place).</li> <li>Passive voice: "ActiveRecord provides methods..." rather than "Methods are provided..."</li> <li>Typo: You've got "t.references :attachement" in a code sample, should be "t.references :attachment"</li> </ul></div> false 2008-09-07T18:50:42+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-07T18:50:55+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Well I'm english so in the absence of guidelines I defaulted to that. I'll fix up the typos and what not too. <div><p>Well I'm english so in the absence of guidelines I defaulted to that. I'll fix up the typos and what not too.</p></div> false 2008-09-07T19:12:54+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-07T19:13:13+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 * You mention that migrations are "not the final word in what an application's schema is". This confuse the reader by giving him the impression that the schema file may be edited in order to to change the application's database schema. You should explain in the first paragraph that the schema file is autogenerated by introspecting the database, and that it should not be edited. It merely represents the final state of the database after having run all migrations (or at least, it's supposed to, because if you dump after having modified the database by hand, then the dump file won't be in sync with the migrations). * You should advice the user about whether or not schema.rb should be put in version control. * I think that "the entire history" in "There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire history of that application." is better worded as "the entire migration history". This avoids confusion with code history. You should also mention that loading the schema is not only simpler, but also faster. * There exists plugins for foreign key support (including dumping and loading) for migrations: http://agilewebdevelopment.com/plugins/search?search=redhillonrails These plugins have a pretty high rating. Might it be a good idea to mention them? <div><ul> <li> <p>You mention that migrations are "not the final word in what an application's schema is". This confuse the reader by giving him the impression that the schema file may be edited in order to to change the application's database schema. You should explain in the first paragraph that the schema file is autogenerated by introspecting the database, and that it should not be edited. It merely represents the final state of the database after having run all migrations (or at least, it's supposed to, because if you dump after having modified the database by hand, then the dump file won't be in sync with the migrations).</p> </li> <li> <p>You should advice the user about whether or not schema.rb should be put in version control.</p> </li> <li> <p>I think that "the entire history" in</p> </li> </ul> <p>"There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire history of that application."</p> <p>is better worded as "the entire migration history". This avoids confusion with code history. You should also mention that loading the schema is not only simpler, but also faster.</p> <ul> <li>There exists plugins for foreign key support (including dumping and loading) for migrations: <a href="http://agilewebdevelopment.com/plugins/search?search=redhillonrails"> http://agilewebdevelopment.com/p...</a> These plugins have a pretty high rating. Might it be a good idea to mention them?</li> </ul></div> false 2008-09-08T12:18:42+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T12:18:45+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Thanks for those comments. I've implemented most of those suggestions, but I'm not entirely sure where I'd mention those plugins. Writing a migration section ? <div><p>Thanks for those comments. I've implemented most of those suggestions, but I'm not entirely sure where I'd mention those plugins. Writing a migration section ?</p></div> false 2008-09-08T12:41:42+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T12:41:48+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I think that a special chapter should be devoted to foreign key support. I can imagine that newcomers might wonder why Rails/ActiveRecord doesn't support foreign key constraints out-of-the-box, so this chapter can explain the reason and link to the plugins. There are several places in the guide that advice the reader to use "execute" for adding foreign key constraints. Those places should link to the foreign key section as well. You could also briefly mention that ActiveRecord's validations (e.g. validates_uniqueness_of) and its :dependent option can be used for managing referential integrity on the application level. They don't *guarantee* referential integrity (they're prone racing conditions, and database modifications outside the application can mess things up) so it's up to the reader to decide whether they need foreign keys. Foreign keys can also be used in addition to ActiveRecord's validations and association management features. <div><p>I think that a special chapter should be devoted to foreign key support. I can imagine that newcomers might wonder why Rails/ActiveRecord doesn't support foreign key constraints out-of-the-box, so this chapter can explain the reason and link to the plugins. There are several places in the guide that advice the reader to use "execute" for adding foreign key constraints. Those places should link to the foreign key section as well.</p> <p>You could also briefly mention that ActiveRecord's validations (e.g. validates_uniqueness_of) and its :dependent option can be used for managing referential integrity on the application level. They don't <em>guarantee</em> referential integrity (they're prone racing conditions, and database modifications outside the application can mess things up) so it's up to the reader to decide whether they need foreign keys. Foreign keys can also be used in addition to ActiveRecord's validations and association management features.</p></div> false 2008-09-08T12:56:02+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T12:56:08+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Sounds like a plan. I'm not actually too familiar with the official reason Active Record doesn't do foreign keys - is this written down somewhere ? <div><p>Sounds like a plan. I'm not actually too familiar with the official reason Active Record doesn't do foreign keys - is this written down somewhere ?</p></div> false 2008-09-08T13:00:29+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:00:32+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I think it would also be a good idea to explain why one wants to use migrations instead of editing the database or an SQL file by hand. For me, it's so that I don't have to tell every other developer on my team what I've changed in the database schema. The changes can be applied in an automated manner. You could also explain why the syntax is in Ruby. This allows a developer to use, for example, SQLite3 in development and MySQL in production, without having to worry about syntactic details of the CREATE TABLE statements. <div><p>I think it would also be a good idea to explain why one wants to use migrations instead of editing the database or an SQL file by hand. For me, it's so that I don't have to tell every other developer on my team what I've changed in the database schema. The changes can be applied in an automated manner.</p> <p>You could also explain why the syntax is in Ruby. This allows a developer to use, for example, SQLite3 in development and MySQL in production, without having to worry about syntactic details of the CREATE TABLE statements.</p></div> false 2008-09-08T13:02:15+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:02:20+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I don't think the lack of foreign key support is written down anywhere. Can anyone from the core team explain? <div><p>I don't think the lack of foreign key support is written down anywhere. Can anyone from the core team explain?</p></div> false 2008-09-08T13:03:05+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:03:08+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Because Rails is designed to work with an application database, and not an integration database. Rails believes only one application is talking ( or should talk ) to the database and treats the database as just one big fat persistent hash. It should be application's responsibility to enforce data integrity. <div><p>Because Rails is designed to work with an application database, and not an integration database. Rails believes only one application is talking ( or should talk ) to the database and treats the database as just one big fat persistent hash. It should be application's responsibility to enforce data integrity.</p></div> false 2008-09-08T13:20:35+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:20:39+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Good points Hongli. I've sort of hinted at them, but it would be good to have them in the open. I don't quite buy the line of data integrity - ruby level checks are subject to race conditions and so on but i'll chuck that in. <div><p>Good points Hongli. I've sort of hinted at them, but it would be good to have them in the open. I don't quite buy the line of data integrity - ruby level checks are subject to race conditions and so on but i'll chuck that in.</p></div> false 2008-09-08T13:24:55+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:25:01+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 There's some discussion in an old DHH blog post, which is no longer online, but you can find quoted at http://lists.rubyonrails.org/pipermail/rails/2006-August/060573.html Also of interest is a comment thread - http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/415d6649294e7fa0/7e8257a2bf5f621a?hl=en&lnk=st&q=rails+%22foreign+keys%22+david+hansson#7e8257a2bf5f621a - where DHH invites anyone who really cares to add FK support to Active Record - though that's 3 years old and I wouldn't necessarily take it to represent current core thinking. <div><p>There's some discussion in an old DHH blog post, which is no longer online, but you can find quoted at <a href="http://lists.rubyonrails.org/pipermail/rails/2006-August/060573.html"> http://lists.rubyonrails.org/pip...</a></p> <p>Also of interest is a comment thread - <a href="http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/415d6649294e7fa0/7e8257a2bf5f621a?hl=en&amp;amp;lnk=st&amp;amp;q=rails+%22foreign+keys%22+david+hansson#7e8257a2bf5f621a"> http://groups.google.com/group/c...</a> - where DHH invites anyone who really cares to add FK support to Active Record - though that's 3 years old and I wouldn't necessarily take it to represent current core thinking.</p></div> false 2008-09-08T13:26:16+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-08T13:26:21+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I've expanded the preamble and waffled about foreign keys. Must be being stupid but I can't get asciidoc to generate links across chapters <div><p>I've expanded the preamble and waffled about foreign keys. Must be being stupid but I can't get asciidoc to generate links across chapters</p></div> false 2008-09-09T02:26:31+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-09T02:26:35+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 To define an anchor: [[anchor_name]] To link to an anchor: <<anchor_name,link title>> Mizuho currently has a bug which causes it not to generate cross-chapter links when in multi-page mode. If you use single page mode (the default) then it will work fine. <div><p>To define an anchor: [[anchor_name]]</p> <p>To link to an anchor: &lt;&lt;anchor_name,link title&gt;&gt;</p> <p>Mizuho currently has a bug which causes it not to generate cross-chapter links when in multi-page mode. If you use single page mode (the default) then it will work fine.</p></div> false 2008-09-09T12:52:21+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-09T12:52:27+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Ah, that explains it. I've stuck the links in. <div><p>Ah, that explains it. I've stuck the links in.</p></div> false 2008-09-09T14:08:09+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-09T14:08:14+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Well done! I'd loved reading this guide and in fact learned a couple of things. I like the content, wording, examples, and the original titles of sections. I've noticed the edition "ActiveRecord" -> "Active Record" from initial versions and overall my impression is that the guide is converging. I just got a few suggestions and have compiled a list of very small things like typos an such. ### _migrations.txt_ ### * In "Migrations also allow you to describe these transformations using ruby" the Ruby language has a capital "R". * "it's" in "its database independent". * Fixed-width font for "schema.rb". ### _anatomy_of_a_migration.txt_ ### * I love you started right away with an example. * Fixed-width font for "products" in "This migration adds a table called products". * Capital "R" for the "ruby" in "A migration is just a regular ruby class". * I think an example that depicts setting values in a new column using a model in the very migration would add here. Then, a pointer to the proper later section would be useful as well. ### _creating_a_migration.txt_ ### * Delete " are also created" in "columns that are automatically populated by Active Record are also created". ### _writing_a_migration.txt_ ### * Fixed-width font for "name" and "id" in "which creates a products table with a column called name (and as discussed below, an implicit id column)". * Fixed-width font for "execute" in "You will need to use execute for that". * Fixed-width font for "up" in "should revert the transformations done by the up method". * Several fixed-width font for "up" and "down" in "The `down` method of your migration should revert the transformations done by the up method. In other words the database should be unchanged if you do an up followed by a down. For example if you create a table in the up you should drop it in the down method. It is wise to do things in precisely the reverse order to in the the up method.". * Fixed-width font for "down" in "you can raise IrreversibleMigration from your down method". ### _rakeing_around.txt ### * Fixed-width font for "up" in "In its most basic form it just runs the up method". * In "If you specify a target version. Active Record will run the required migrations" the dot is a comma. * "will run all the up method" should read "will run all the `up` methods". * Fixed-width font for "down" in "this will run the down method". * Fixed-width font for "down" in "This will run the down method". * Fixed-width font for "down" in "will run the down method". * I think it would be good to give a use case for db:migrate:redo. * Fixed-width font for "up" and "down" in "the corresponding migration will have its up or down method invoked". * Fixed-width font for "up" in "will run the up method from the 20080906120000 migration". ### _using_models_in_migrations.txt_ ### * "SQL" in "without writing out the sql by hand". * "not using" in "I'm notusing anything". ### _scheming.txt_ ### * gsub!("sql", "SQL") * In "Instead of using Active Record 's schema dumper" remove space to the left of the apostrophe. * "will dumped" should be I think "will be dumped". * "postgresql" -> "PostgreSQL". * "mysql" -> "MySQL" * Since tables are incrementally defined one may wonder where to check models attributes, mention schema.rb and annotate_models? ### _foreign_keys.txt_ ### * I think there's (or there was) some gotcha about destroying data in tests and FKs. If I recall it correctly AR just drops data without any particular order and FKs interfere there. I believe it would be worth exploring and documenting some workaround or best practice here. (Assuming the gotcha still exists.) ### Additional remarks ### * Albeit not really about migrations, I think some coverage of rake db:create would kind of round the guide. It is related to db:reset which is indeed mentioned. It could say something about the grants of the user configured in database.yml as well, though perhaps wouldn't be necessary to explain database.yml itself, nor the keys used to configure databases. <div><p>Well done!</p> <p>I'd loved reading this guide and in fact learned a couple of things. I like the content, wording, examples, and the original titles of sections.</p> <p>I've noticed the edition "ActiveRecord" -&gt; "Active Record" from initial versions and overall my impression is that the guide is converging.</p> <p>I just got a few suggestions and have compiled a list of very small things like typos an such.</p> <h3><em>migrations.txt</em></h3> <ul> <li> <p>In "Migrations also allow you to describe these transformations using ruby" the Ruby language has a capital "R".</p> </li> <li> <p>"it's" in "its database independent".</p> </li> <li> <p>Fixed-width font for "schema.rb".</p> </li> </ul> <h3><em>anatomy_of_a_migration.txt</em></h3> <ul> <li> <p>I love you started right away with an example.</p> </li> <li> <p>Fixed-width font for "products" in "This migration adds a table called products".</p> </li> <li> <p>Capital "R" for the "ruby" in "A migration is just a regular ruby class".</p> </li> <li> <p>I think an example that depicts setting values in a new column using a model in the very migration would add here. Then, a pointer to the proper later section would be useful as well.</p> </li> </ul> <h3><em>creating_a_migration.txt</em></h3> <ul> <li>Delete " are also created" in "columns that are automatically populated by Active Record are also created".</li> </ul> <h3><em>writing_a_migration.txt</em></h3> <ul> <li> <p>Fixed-width font for "name" and "id" in "which creates a products table with a column called name (and as discussed below, an implicit id column)".</p> </li> <li> <p>Fixed-width font for "execute" in "You will need to use execute for that".</p> </li> <li> <p>Fixed-width font for "up" in "should revert the transformations done by the up method".</p> </li> <li> <p>Several fixed-width font for "up" and "down" in "The <code>down</code> method of your migration should revert the transformations done by the up method. In other words the database should be unchanged if you do an up followed by a down. For example if you create a table in the up you should drop it in the down method. It is wise to do things in precisely the reverse order to in the the up method.".</p> </li> <li> <p>Fixed-width font for "down" in "you can raise IrreversibleMigration from your down method".</p> </li> </ul> <h3>_rakeing_around.txt</h3> <ul> <li> <p>Fixed-width font for "up" in "In its most basic form it just runs the up method".</p> </li> <li> <p>In "If you specify a target version. Active Record will run the required migrations" the dot is a comma.</p> </li> <li> <p>"will run all the up method" should read "will run all the <code>up</code> methods".</p> </li> <li> <p>Fixed-width font for "down" in "this will run the down method".</p> </li> <li> <p>Fixed-width font for "down" in "This will run the down method".</p> </li> <li> <p>Fixed-width font for "down" in "will run the down method".</p> </li> <li> <p>I think it would be good to give a use case for db:migrate:redo.</p> </li> <li> <p>Fixed-width font for "up" and "down" in "the corresponding migration will have its up or down method invoked".</p> </li> <li> <p>Fixed-width font for "up" in "will run the up method from the 20080906120000 migration".</p> </li> </ul> <h3><em>using_models_in_migrations.txt</em></h3> <ul> <li> <p>"SQL" in "without writing out the sql by hand".</p> </li> <li> <p>"not using" in "I'm notusing anything".</p> </li> </ul> <h3><em>scheming.txt</em></h3> <ul> <li> <p>gsub!("sql", "SQL")</p> </li> <li> <p>In "Instead of using Active Record 's schema dumper" remove space to the left of the apostrophe.</p> </li> <li> <p>"will dumped" should be I think "will be dumped".</p> </li> <li> <p>"postgresql" -&gt; "PostgreSQL".</p> </li> <li> <p>"mysql" -&gt; "MySQL"</p> </li> <li> <p>Since tables are incrementally defined one may wonder where to check models attributes, mention schema.rb and annotate_models?</p> </li> </ul> <h3><em>foreign_keys.txt</em></h3> <ul> <li>I think there's (or there was) some gotcha about destroying data in tests and FKs. If I recall it correctly AR just drops data without any particular order and FKs interfere there. I believe it would be worth exploring and documenting some workaround or best practice here. (Assuming the gotcha still exists.)</li> </ul> <h3>Additional remarks</h3> <ul> <li>Albeit not really about migrations, I think some coverage of rake db:create would kind of round the guide. It is related to db:reset which is indeed mentioned. It could say something about the grants of the user configured in database.yml as well, though perhaps wouldn't be necessary to explain database.yml itself, nor the keys used to configure databases.</li> </ul></div> false 2008-09-11T00:17:16+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-11T00:17:23+01:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Wow Xavier, thanks for reading so closely! I've fixed/pushed the typo and similar sorts of corrections the ones where I need to do some thinking I'll do at some point later today. Foreign keys: I think that's all been fixed for a while - I use foreign keys all the time and haven't had any problems. AR disables referential integrity while loads fixtures and stuff like that. Your last point about scheming.txt - I'm not quite sure what you mean there. <div><p>Wow Xavier, thanks for reading so closely! I've fixed/pushed the typo and similar sorts of corrections the ones where I need to do some thinking I'll do at some point later today.</p> <p>Foreign keys: I think that's all been fixed for a while - I use foreign keys all the time and haven't had any problems. AR disables referential integrity while loads fixtures and stuff like that.</p> <p>Your last point about scheming.txt - I'm not quite sure what you mean there.</p></div> false 2008-09-11T10:26:34+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-11T10:26:51+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Hey that was quick! :-) What I mean in that last point is: AR models do not have their attributes declared in the source code, and the definition of the PRODUCTS table may be scattered in three migrations. So the question is where can I have a look at the current list of attributes of the Product class? A database client is a solution, but I wondered whether it could be worth to mention in scheming.txt that schema.rb is a handy place where you can look at them. And to complete the remark perhaps mention the annotate_models plugin. <div><p>Hey that was quick! :-)</p> <p>What I mean in that last point is: AR models do not have their attributes declared in the source code, and the definition of the PRODUCTS table may be scattered in three migrations. So the question is where can I have a look at the current list of attributes of the Product class?</p> <p>A database client is a solution, but I wondered whether it could be worth to mention in scheming.txt that schema.rb is a handy place where you can look at them. And to complete the remark perhaps mention the annotate_models plugin.</p></div> false 2008-09-11T10:57:31+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-11T10:57:41+01:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Ah, I get you! I'm not actually familiar with annotate_models, I'll have a look <div><p>Ah, I get you! I'm not actually familiar with annotate_models, I'll have a look</p></div> false 2008-09-11T11:05:30+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-11T11:05:38+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I've made those other changes. <div><p>I've made those other changes.</p></div> false 2008-09-11T14:06:03+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-11T14:06:10+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 "create_table :products, :options => "ENGINE=InnoDB" do |t|" Maybe it would be nice to mention that InnoDB, rather than MyISAM, is Rails's default when on MySQL. <div><p>"create_table :products, :options =&gt; "ENGINE=InnoDB" do |t|"</p> <p>Maybe it would be nice to mention that InnoDB, rather than MyISAM, is Rails's default when on MySQL.</p></div> false 2008-09-12T11:52:29+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-12T11:52:47+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Yup, don't see why not. <div><p>Yup, don't see why not.</p></div> false 2008-09-12T12:44:26+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-12T12:44:36+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 I've just thoroughly read your guide one last time. Be prepared for nitpicks. :) "rake" -- should be "Rake" "and an error ensues." -- I think "and an error ensues because that validation fails." would be nicer because it's more explicit. "On databases that support transactions with statements that change the schema" -- I think it would be nice to specifically mention that PostgreSQL supports DDL transactions, seeing that Postgres is pretty popular. And I think "Mysql" should be "MySQL". :) "There are two ways of the doing this." -- "the" should be erased. "The references helper does not actually create foreign key constraints for you. You will need to use execute for that." -- I think "You will need to use execute for that, or a [link]foreign key support plugin[/link]" "For more details and examples of individual methods check the API documentation." -- Please specifically refer to the ActiveRecord::ConnectionAdapters::SchemaStatements class and the ActiveRecord::ConnectionAdapters::TableDefinition class. SchemaStatements methods are available in the 'up' and 'down' methods while TableDefinition methods are available through the 't' object. "Almost all the functionality provided by other rake tasks could be done using db:migrate but would be more tedious (partly because of the long version numbers you would have to lookup and enter)." - I don't really understand this statement. Could you clarify a little more? "Rather than track down the version number associated with the previous migration you can run" -- I believe that "track down" here is grammatically incorrect and should be "tracking down". Also, the examples that you show in that subsection, e.g. "rake db:rollback", should be listing blocks. "this is not the same as running all the migrations - see the section on schema.rb)." -- "This" should be capitalized, and the trailing ")" should be removed. "the current development database is dumped (either to schema.rb or development.sql) and then loaded." -- "loaded into the test database." would be better. "These cannot however guarantee referential integrity" -- I think you should explicitly mention that that's because nothing at application level can guarantee referential integrity, otherwise the reader might think the inability to guarantee integrity is caused by bugs or limitations in ActiveRecord. Everything above the database level is prone to racing conditions, unless they use expensive database locks. "(including support in schema.rb)." -- should be "(including support for dumping foreign keys to schema.rb)." Anyway, good job! I think the guide is as good as done, unless you or anyone else thinks otherwise. <div><p>I've just thoroughly read your guide one last time. Be prepared for nitpicks. :)</p> <p>"rake" -- should be "Rake"</p> <p>"and an error ensues." -- I think "and an error ensues because that validation fails." would be nicer because it's more explicit.</p> <p>"On databases that support transactions with statements that change the schema" -- I think it would be nice to specifically mention that PostgreSQL supports DDL transactions, seeing that Postgres is pretty popular. And I think "Mysql" should be "MySQL". :)</p> <p>"There are two ways of the doing this." -- "the" should be erased.</p> <p>"The references helper does not actually create foreign key constraints for you. You will need to use execute for that." -- I think "You will need to use execute for that, or a [link]foreign key support plugin[/link]"</p> <p>"For more details and examples of individual methods check the API documentation." -- Please specifically refer to the ActiveRecord::ConnectionAdapters::SchemaStatements class and the ActiveRecord::ConnectionAdapters::TableDefinition class. SchemaStatements methods are available in the 'up' and 'down' methods while TableDefinition methods are available through the 't' object.</p> <p>"Almost all the functionality provided by other rake tasks could be done using db:migrate but would be more tedious (partly because of the long version numbers you would have to lookup and enter)." - I don't really understand this statement. Could you clarify a little more?</p> <p>"Rather than track down the version number associated with the previous migration you can run" -- I believe that "track down" here is grammatically incorrect and should be "tracking down". Also, the examples that you show in that subsection, e.g. "rake db:rollback", should be listing blocks.</p> <p>"this is not the same as running all the migrations - see the section on schema.rb)." -- "This" should be capitalized, and the trailing ")" should be removed.</p> <p>"the current development database is dumped (either to schema.rb or development.sql) and then loaded." -- "loaded into the test database." would be better.</p> <p>"These cannot however guarantee referential integrity" -- I think you should explicitly mention that that's because nothing at application level can guarantee referential integrity, otherwise the reader might think the inability to guarantee integrity is caused by bugs or limitations in ActiveRecord. Everything above the database level is prone to racing conditions, unless they use expensive database locks.</p> <p>"(including support in schema.rb)." -- should be "(including support for dumping foreign keys to schema.rb)."</p> <p>Anyway, good job! I think the guide is as good as done, unless you or anyone else thinks otherwise.</p></div> false 2008-09-13T12:33:40+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-13T12:34:11+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Cool I'll make those changes. By "Almost all the functionality provided by other rake tasks could be done using db:migrate but would be more tedious (partly because of the long version numbers you would have to lookup and enter" I mean that you can replicate rake db:rollback by finding the appropriate version and running rake db:migrate VERSION=xxxx, similarly with :redo and so on. I can see that it's not very clear. Perhaps it will be clearer if I put a reworded version of this after the description of the relevant rake tasks. <div><p>Cool I'll make those changes.</p> <p>By "Almost all the functionality provided by other rake tasks could be done using db:migrate but would be more tedious (partly because of the long version numbers you would have to lookup and enter" I mean that you can replicate rake db:rollback by finding the appropriate version and running rake db:migrate VERSION=xxxx, similarly with :redo and so on. I can see that it's not very clear. Perhaps it will be clearer if I put a reworded version of this after the description of the relevant rake tasks.</p></div> false 2008-09-13T16:53:05+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-13T17:17:47+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Forgot to say, I also think this is basically done (typos etc. aside). <div><p>Forgot to say, I also think this is basically done (typos etc. aside).</p></div> false 2008-09-13T22:02:27+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-13T22:02:36+01:00 17477 Frederick Cheung Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Yeah, agreed. <div><p>Yeah, agreed.</p></div> false 2008-09-13T22:18:23+01:00 1366 --- {} 6 migrations-guide 0 16213 new 2008-09-13T22:18:30+01:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 true 2008-09-14T13:05:32+01:00 1366 --- :state: new 6 migrations-guide 0 16213 resolved 2008-09-14T13:06:00+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Section 1.1 says "Active Record provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later):" but then most of those methods (like change_column or add_index) aren't explicitly discussed in the text - they're mentioned in passing or not at all. Seems like either 1.1 needs to be reworded, or else we need sections somewhere on the various methods. <div><p>Section 1.1 says "Active Record provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later):" but then most of those methods (like change_column or add_index) aren't explicitly discussed in the text - they're mentioned in passing or not at all. Seems like either 1.1 needs to be reworded, or else we need sections somewhere on the various methods.</p></div> true 2008-09-22T15:25:15+01:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-09-22T15:25:20+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 typo. 4.1. Rolling back will run the down method ***fron*** the last 3 migrations <div><p>typo.</p> <p>4.1. Rolling back</p> <p>will run the down method <strong><em>fron</em></strong> the last 3 migrations</p></div> true 2008-11-02T05:46:05+00:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-11-02T05:46:10+00:00 18874 ZhangJinzhu Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Typo fixed in the repo, thank you! <div><p>Typo fixed in the repo, thank you!</p></div> true 2008-11-02T13:56:56+00:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-11-02T13:57:01+00:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 How do you migrate the database on a production server with source control? Do you update the schema.rb file on the production server and then run db:reset? Should we not use db:migrate? <div><p>How do you migrate the database on a production server with source control? Do you update the schema.rb file on the production server and then run db:reset? Should we not use db:migrate?</p></div> true 2008-11-06T18:36:49+00:00 1366 --- :tag: 6 migrations-guide 0 16213 resolved migrate production schema svn 2008-11-06T18:36:55+00:00 36690 Your name Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Removing tags. <div><p>Removing tags.</p></div> true 2008-11-06T18:37:41+00:00 1366 --- :tag: migrate production schema svn 6 migrations-guide 0 16213 resolved 2008-11-06T18:37:45+00:00 36690 Your name Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 "Schema files are also useful if want a quick look at what attributes an Active Record object has." should presumably be "Schema files are also useful if you want a quick look at what attributes an Active Record object has." <div><p>"Schema files are also useful if want a quick look at what attributes an Active Record object has." should presumably be "Schema files are also useful if you want a quick look at what attributes an Active Record object has."</p></div> true 2008-11-09T05:03:31+00:00 1366 --- :tag: :title: Migrations guide 6 migrations-guide 0 16213 resolved grammar 2008-11-09T05:03:34+00:00 28039 Brandon Zylstra Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 true 2008-11-09T05:04:32+00:00 1366 --- :tag: grammar :title: missing word "you" 6 migrations-guide 0 16213 resolved 2008-11-09T05:04:35+00:00 28039 Brandon Zylstra Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 There is a comma missing in this sentence: As such features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used. This might sound like a nit-pick, but it is much clearer with the comma: As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used. <div><p>There is a comma missing in this sentence:</p> <pre> <code>As such features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used. </code> </pre> <p>This might sound like a nit-pick, but it is much clearer with the comma:</p> <p>As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used.</p></div> true 2008-11-09T05:15:18+00:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-11-09T05:15:22+00:00 28039 Brandon Zylstra Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Thank you Brandon, I revised both details in the repo. Please, if you liked to be able to fix docs yourself join docrails! Just drop a line to Pratik. <div><p>Thank you Brandon, I revised both details in the repo.</p> <p>Please, if you liked to be able to fix docs yourself join docrails! Just drop a line to Pratik.</p></div> true 2008-11-09T09:12:56+00:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-11-09T09:13:00+00:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Some things I think need to be added to this migrations guide is a explanation of the options for columns in the create_table and add_column migrations, like: :limit => 12 :default => 23 :default => false (on boolean columns) :precision => 15, :scale => 3 (on decimal columns) etc. I see :null => false in there, but that's it. They are optional, but certainly helpful if you're making a string column that only needs 5 characters, that it's known you can use :limit => 5 if you want. <div><p>Some things I think need to be added to this migrations guide is a explanation of the options for columns in the create_table and add_column migrations, like:</p> <p>:limit =&gt; 12 :default =&gt; 23 :default =&gt; false (on boolean columns) :precision =&gt; 15, :scale =&gt; 3 (on decimal columns)</p> <p>etc.</p> <p>I see :null =&gt; false in there, but that's it. They are optional, but certainly helpful if you're making a string column that only needs 5 characters, that it's known you can use :limit =&gt; 5 if you want.</p></div> true 2008-11-25T19:32:39+00:00 1366 --- {} 6 migrations-guide 0 16213 resolved 2008-11-25T19:32:42+00:00 27230 Bill Turner Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 0 5.1 Dealing With Changing Models In the code example: add_column :product, :part_number, :string Should read: add_column 'product', :part_number, :string or rake will fail. Tiny nit-pick about use of English in the same section: "...model to insert a new row it may try and use the old column information." Should be "try to", not "try and". <div><p>5.1 Dealing With Changing Models</p> <p>In the code example:</p> <pre> <code>add_column :product, :part_number, :string </code> </pre> <p>Should read:</p> <p>add_column 'product', :part_number, :string</p> <p>or rake will fail.</p> <p>Tiny nit-pick about use of English in the same section: "...model to insert a new row it may try and use the old column information." Should be "try to", not "try and".</p></div> true 2009-05-04T09:58:57+01:00 1366 --- :state: resolved :assigned_user: 1366 6 migrations-guide 0 16213 2009-05-04T09:59:01+01:00 55960 FelixLeiter Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Hey, using symbols for table names certainly works. We've edited the "try and" though http://github.com/lifo/docrails/commit/912da7fb98cfdabe68477db146eaf25bb98f0f7e Thanks! <div><p>Hey, using symbols for table names certainly works. We've edited the "try and" though <a href="http://github.com/lifo/docrails/commit/912da7fb98cfdabe68477db146eaf25bb98f0f7e"> http://github.com/lifo/docrails/...</a></p> <p>Thanks!</p></div> true 2009-05-04T20:18:01+01:00 1366 --- :assigned_user: 6 migrations-guide 0 16213 2009-05-04T20:18:06+01:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 One link in chapter "7 Active Record and Referential Integrity" does not work. "There are also a number of plugins such as _redhillonrails_ which add foreign key support to Active Record (including support for dumping foreign keys in db/schema.rb)" Link could be fixed to e.g. http://github.com/harukizaemon/foreign_key_migrations/ (best i could find) In addition, there could be a link to foreign_key_migrations plugin (http://github.com/harukizaemon/foreign_key_migrations) inside the parentheses. That plugin brings the support for dumping foreign keys in db/schema.rb. <div><p>One link in chapter "7 Active Record and Referential Integrity" does not work.</p> <p>"There are also a number of plugins such as <em>redhillonrails</em> which add foreign key support to Active Record (including support for dumping foreign keys in db/schema.rb)"</p> <p>Link could be fixed to e.g. <a href= "http://github.com/harukizaemon/foreign_key_migrations/">http://github.com/harukizaemon/foreign_key_migrations/</a> (best i could find)</p> <p>In addition, there could be a link to foreign_key_migrations plugin (<a href= "http://github.com/harukizaemon/foreign_key_migrations">http://github.com/harukizaemon/foreign_key_migrations</a>) inside the parentheses. That plugin brings the support for dumping foreign keys in db/schema.rb.</p></div> true 2009-06-29T22:46:36+01:00 1366 --- {} 6 migrations-guide 0 16213 2009-06-29T22:46:38+01:00 48866 holli Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Link updated, thank you! <div><p>Link updated, thank you!</p></div> true 2009-07-02T13:59:09+01:00 1366 --- :state: 6 migrations-guide 0 16213 published 2009-07-02T13:59:16+01:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Something that should be added to the migrations page: `rename_table` I'd be happy to add it myself, but it'd probably be a small enough change for someone who already has access to make. <div><p>Something that should be added to the migrations page: <code>rename_table</code></p> <p>I'd be happy to add it myself, but it'd probably be a small enough change for someone who already has access to make.</p></div> true 2009-08-24T20:28:00+01:00 1366 --- {} 6 migrations-guide 0 16213 published 2009-08-24T20:28:02+01:00 33958 Zach Hale Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6 1366 0 Sometimes, students finish the english dissertation by their own efforts. But some of them like to buy the useful theme close to this good post from the <a href="http://www.master-dissertations.com">thesis</a> service, just because it’s more easy. <div><p>Sometimes, students finish the english dissertation by their own efforts. But some of them like to buy the useful theme close to this good post from the <a href= "http://www.master-dissertations.com">thesis</a> service, just because it&#8217;s more easy.</p></div> true 2010-01-30T05:40:23+00:00 1366 --- {} 6 migrations-guide 0 16213 published 2010-01-30T08:48:26+00:00 84603 CHLOE18nL Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/6