gmane.comp.lang.ruby.rails

Stedwick | 16 May 03:27

Combine old migrations?


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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Ryan Bigg (Radar | 16 May 03:31

Re: Combine old migrations?

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
-~----------~----~----~----~------~----~------~--~---

headers

AndyV | 16 May 20:55

Re: Combine old migrations?

<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...@...>
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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Nathan Esquenazi | 18 May 01:44

Re: Combine old migrations?


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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Jeremy McAnally | 18 May 01:51

Re: Combine old migrations?


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@...> 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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Ryan Bigg (Radar | 19 May 03:58

Re: Combine old migrations?

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
-~----------~----~----~----~------~----~------~--~---

headers

Ryan Bigg (Radar | 19 May 03:59

Re: Combine old migrations?

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
-~----------~----~----~----~------~----~------~--~---

headers

Rick DeNatale | 19 May 13:13

Re: Combine old migrations?

On Sun, May 18, 2008 at 9:59 PM, Ryan Bigg (Radar)
<radarlistener@...> 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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

AndyV | 19 May 17:31

Re: Combine old migrations?


> 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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Ryan Bigg (Radar | 20 May 06:01

Re: Combine old migrations?

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
-~----------~----~----~----~------~----~------~--~---

headers

Nathan Esquenazi | 20 May 06:16

Re: Combine old migrations?


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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Ryan Bigg (Radar | 20 May 06:18

Re: Combine old migrations?

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
-~----------~----~----~----~------~----~------~--~---

headers

Stedwick | 18 May 01:45

Re: Combine old migrations?


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...@...> 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...@...>
> 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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---