How do I take, say, 20 of my older migrations and wrap them up into only a single one in order to clean up my directory? Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Not a good idea. If you think 20 is a bad number I''d hate to see if you''d work on a big project (100+ migrations) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
<rant> @Ryan, Do you ever stop to consider that people have very good reasons to do things that you might not do? I''m getting tired of seeing responses like "Gee I wouldn''t do that" or "it''s dumb to have that javascript turned off" or ... It''d be a lot more helpful, if you''re that enlightened, if you would both explain how to do it AND SUGGEST why it is not considered a good idea. That said, consider this. One site that I''m working on currently has 150+ migrations for about 120 tables. By your logic I''d be dumb to combine them. But it''s quite possible that this app will be deployed both publicly (hosting for small customers) and privately (intranet for very large customers). I''m perfectly willing to keep creating migrations when necessary for the public side, but if I am doing a fresh install on a private site, what sense does it make to deploy the 20-30 migrations that are patched and overridden by later ones? Wouldn''t a single, clean migration script serve those customers much better? </rant> @Stedwick -- rake db:schema:dump should give you pretty much what you''re looking for. I''ll let you discern from the previous comments whether or not YOU think it''s a good idea. :) Cheers. On May 15, 9:31 pm, "Ryan Bigg (Radar)" <radarliste...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Not a good idea. > > If you think 20 is a bad number I''d hate to see if you''d work on a big > project (100+ migrations)--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
From schema.rb # Note that this schema.rb definition is the authoritative source for your database schema. If you need # to create the application database on another system, you should be using db:schema:load, not running # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations # you''ll amass, the slower it''ll run and the greater likelihood for issues). In short, one reason you don''t really need to consolidate migrations is because when deploying a application to a new server, you should really not use db:migrate because it can be slow, amass alot of redundancy, etc. Loading the latest schema is a much better practice. so when starting from scratch use: rake db:schema:load over rake db:migrate (in most cases) That said, I don''t think consolidating old migrations is necessarily bad if its a personal project and no one else is relying on the migrations. In fact, before a project is deployed for release, I tend to use: http://errtheblog.com/posts/65-automatically -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks, Andy! I knew there was some really easy way to do it. I figure, I have all my old migrations in subversion anyway, just in case, and when will I ever really need the first couple again? I''m not going to roll back my entire application :-) On May 16, 2:55 pm, AndyV <AndyVana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> <rant> > @Ryan, Do you ever stop to consider that people have very good reasons > to do things that you might not do? I''m getting tired of seeing > responses like "Gee I wouldn''t do that" or "it''s dumb to have that > javascript turned off" or ... It''d be a lot more helpful, if you''re > that enlightened, if you would both explain how to do it AND SUGGEST > why it is not considered a good idea. > > That said, consider this. One site that I''m working on currently has > 150+migrationsfor about 120 tables. By your logic I''d be dumb tocombinethem. But it''s quite possible that this app will be deployed > both publicly (hosting for small customers) and privately (intranet > for very large customers). I''m perfectly willing to keep creatingmigrationswhen necessary for the public side, but if I am doing a > fresh install on a private site, what sense does it make to deploy the > 20-30migrationsthat are patched and overridden by later ones? > Wouldn''t a single, clean migration script serve those customers much > better? > </rant> > > @Stedwick -- rake db:schema:dump should give you pretty much what > you''re looking for. I''ll let you discern from the previous comments > whether or not YOU think it''s a good idea. :) > > Cheers. > > On May 15, 9:31 pm, "Ryan Bigg (Radar)" <radarliste...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > > > Not a good idea. > > > If you think 20 is a bad number I''d hate to see if you''d work on a big > > project (100+migrations)- Hide quoted text - > > - Show quoted text ---~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Right. Schema loading is just for that purpose; migrating is just for incremental updates to the schema. Even better, when you load schema.rb, it''ll set the proper version so you can pick up from there using migrations just like it would if you were to do db:migrate. This discrepancy is one of the biggest reasons you should never have data/logic in your migrations. If you do a schema:load, then you miss out on whatever seed data is in the migration. You should instead create something like rake db:bootstrap in lib/tasks or something. --Jeremy On Sat, May 17, 2008 at 7:44 PM, Nathan Esquenazi <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > From schema.rb > > # Note that this schema.rb definition is the authoritative source for > your database schema. If you need > # to create the application database on another system, you should be > using db:schema:load, not running > # all the migrations from scratch. The latter is a flawed and > unsustainable approach (the more migrations > # you''ll amass, the slower it''ll run and the greater likelihood for > issues). > > In short, one reason you don''t really need to consolidate migrations is > because when deploying a application to a new server, you should really > not use db:migrate because it can be slow, amass alot of redundancy, > etc. Loading the latest schema is a much better practice. > > so when starting from scratch use: > > rake db:schema:load > > over > > rake db:migrate > > (in most cases) > > That said, I don''t think consolidating old migrations is necessarily bad > if its a personal project and no one else is relying on the migrations. > > In fact, before a project is deployed for release, I tend to use: > > http://errtheblog.com/posts/65-automatically > -- > Posted via http://www.ruby-forum.com/. > > > >-- http://jeremymcanally.com/ http://entp.com Read my books: Ruby in Practice (http://manning.com/mcanally/) My free Ruby e-book (http://humblelittlerubybook.com/) Or, my blogs: http://mrneighborly.com http://rubyinpractice.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
OK, so you wanted a "Why?", here''s one. I create many migration files, lets say 20, with matching models in them is one called "Person". All of a sudden, I realise I don''t like having it called Person and I never liked the idea of having a persons table. If I had combined my twenty migrations into one big migrations file I am now going to have to go looking through this HUGE file for my persons table, delete the entry, and then continue on my merry way. If I had a single file I could delete that file easily because I know what to expect when looking for it and I know exactly where it''s going to be and I don''t have to dig through a hundred lines looking for it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
And before you say it, yes I could create a new migration and call drop_table in it, but then that defeats the purpose of only having one migration file. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, May 18, 2008 at 9:59 PM, Ryan Bigg (Radar) <radarlistener-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> And before you say it, > > yes I could create a new migration and call drop_table in it, but then that > defeats the purpose of only having one migration file.Having only one migration file (per table?) gives the impression that you are creating one migration file for each table, and when you want to change the schema, you change the migration and go back and rerun all the migrations? If so this seems antithetical to the reason for migrations which is to keep the history of changes to the DB schema as a series of deltas. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> OK, so you wanted a "Why?", here''s one. > > I create many migration files, lets say 20, with matching models in them is > one called "Person". All of a sudden, I realise I don''t like having it > called Person and I never liked the idea of having a persons table. If I had > combined my twenty migrations into one big migrations file I am now going to > have to go looking through this HUGE file for my persons table, delete the > entry, and then continue on my merry way. If I had a single file I could > delete that file easily because I know what to expect when looking for it > and I know exactly where it''s going to be and I don''t have to dig through a > hundred lines looking for it.Good, Ryan. But you miss my point. You have a tendency to present your opinion/preference as fact. My suggestion is instead to defer to the wisdom of the developer in his or her own context. As you post your recommendation, assume that the developer has the ability to discern whether or not your approach fits their context. You do that by giving the pro/con of your approach. BTW, there is only one ''c'' in Recommend. You might want to change that in your sig if you hope to attract would-be employers. Folks (like me) who are looking for Rails help see typos like that as an indicator of the level of attention you pay to details, especially when ''Recommend'' can be copied and pasted from the WWR site. Good luck. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > > BTW, there is only one ''c'' in Recommend. You might want to change > that in your sig if you hope to attract would-be employers. Folks > (like me) who are looking for Rails help see typos like that as an > indicator of the level of attention you pay to details, especially > when ''Recommend'' can be copied and pasted from the WWR site. > > Good luck. > >I''m currently happily employed, and "Reccommend" was a typo. If this was code it would''ve thrown a syntax error, which I would''ve corrected right away, remembered my mistake and never do it again. Employers should not judge people''s programming skills by the amount of words they mistype in a sentence. -- Appreciated my help? Recommend me on Working With Rails http://workingwithrails.com/person/11030-ryan-bigg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
To be fair, If I was looking at a resume and it was filled with typos then that would be a cause for concern in my opinion. Not the typos themselves but the lack of respect and professionalism in that the person did not care to correct their resume before submission. Typos on a forum or on any casual internet medium seem to be a pretty bad way to judge a potential employee. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Bad Cover Letter: Hai. I ams teh looking to joun ur companies. Plz 2b reding thru resume attachd. thx! On Tue, May 20, 2008 at 1:46 PM, Nathan Esquenazi < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > To be fair, If I was looking at a resume and it was filled with typos > then that would be a cause for concern in my opinion. Not the typos > themselves but the lack of respect and professionalism in that the > person did not care to correct their resume before submission. Typos on > a forum or on any casual internet medium seem to be a pretty bad way to > judge a potential employee. > -- > Posted via http://www.ruby-forum.com/. > > > >-- Appreciated my help? Recommend me on Working With Rails http://workingwithrails.com/person/11030-ryan-bigg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---