[Rails] [ANN] DevTower Beta3 Release!

[Tobias Lütke]

Migrations are ruby code which runs in your rails environment. Data is
meant to be converted and adjusted by them. In fact of Shopify's 146
migrations only about 100 actually change the schema.rb. Most deal
with data transformation. Shopify is not in production mode yet ( well
it's going to be later today )

On 4/13/06, Hampton <hcatlin at gmail.com> wrote:
> Tobias,
>
> The main issue here is.... when I add a row called "created_on" to my user
> table and I make a migration for it. Then, my fellow developer grabs the new
> source, and runs the migration. Then, he has a broken data-set. None of the
> created_ons in his user are filled out!

User.find(:all).each { |u| u.update_attribute(:created_on,
Time.parse("#{rand(27)+1}-#{rand(11)+1}-2005"))  }

cheers.


>
> There is only merging of structure, not data.
>
> So, tell me how doing small migrations would keep that from happening?
>
> Later on when we have a production server, we'd write stuff into our
> migration to generate the correct data, because its worth taking the time to
> do that to migrate an existing stable database.
>
> The other issue here is when you have a large set of data. For instance, I
> was working on a system for keeping events data. Well, I would enter 5
> events as I was developing one day, then my partner-in-crime would enter 4
> on hers... We both wanted that shared information to be merged.
>
> So, this provides a serialized database in its entirety. Also, what if I do
> early development on sqlite and want to move *all* of my existing data over
> to some other database type. This system would use database serialization to
> facilitate that.
>
> Last comment, lots of people will find this horrible un-useful to their
> work-habits. However, using migrations early on often left me and my other
> developers with odd looking database datasets that would break and were a
> pain in the neck to keep up with all the changes that were happening. So,
> this certainly isn't for everyone, but it is something that others who
> develop in a style similar to mine might find useful.
>
> -hampton.
>
>
> On 4/13/06, Tobias Lütke <tobias.luetke at gmail.com> wrote:
> >
>  Just for the record: Thats absolutely not my experience. Migrations
> work very well during all phases of the development if you
>
>   a) Check in often
>   b) Make lots of small migrations instead of one big.
>
>  tip: Lock a file in the repository when creating a migration until its
> checked in. This will give your fellow developers a heads up that they
> should wait for you.
>
> > ===== BIG QUESTION =====
> >
> > What about migrations?
> >     migrations are great when you are working with a stable/production
> > database
> >     and have muiltiple branches. but, we use schema.rb to keep things in
> > line early in
> >     development before branching and before stability... really good for
> > when the database is
> >      changingoften and radically. migrations are great for small changes,
> > painful for large
> >     ones very often.
> _______________________________________________
>  Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
Tobi
http://shopify.com       - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog