Is migrations support planned for Cake?

[the_woodsman]

Having written my first cake test case the other day, it got me
thinking that the mechanisms for creating tables, fixtures etc, and
tearing them down when finished... well, its half way to an
infrstructure for DB migrations, no? Especially if it could be
combined with some kind of Migratable behaviour?

Searches for Cake migrations don't reveal any offical ones, and I
don't want to work with YAML etc.

Are they any steps towards offical cake migrations features, I'd be
interested in taking a look, even if they're not very advanced...?

[John David Anderson]

On May 17, 2008, at 3:17 PM, the_woodsman wrote:

> Are they any steps towards offical cake migrations features, I'd be
> interested in taking a look, even if they're not very advanced...?

Check out the Cake schema console.

-- John

[Keith]

http://cakebaker.42dh.com/2008/04/13/migrations-the-cakephp-way/

On May 17, 5:17 pm, the_woodsman <elwood.ca...-***@public.gmane.org> wrote:
> Having written my first cake test case the other day, it got me
> thinking that the mechanisms for creating tables, fixtures etc, and
> tearing them down when finished... well, its half way to an
> infrstructure for DB migrations, no? Especially if it could be
> combined with some kind of Migratable behaviour?
>
> Searches for Cake migrations don't reveal any offical ones, and I
> don't want to work with YAML etc.
>
> Are they any steps towards offical cake migrations features, I'd be
> interested in taking a look, even if they're not very advanced...?

[joelmoss]

Cake currently has a migrations-like schema shell, but it only allows
you to create tables. You cannot make changes to existing tables, and
cannot roll back your changes. There is an unofficial Migrations shell
available at http://code.google.com/p/cakephp-migrations/, which is a
full DB migrations system. I am hoping to see this being introduced in
the next version of Cake (v2.0).

Joel


On May 17, 10:17 pm, the_woodsman <elwood.ca...-***@public.gmane.org> wrote:
> Having written my first cake test case the other day, it got me
> thinking that the mechanisms for creating tables, fixtures etc, and
> tearing them down when finished... well, its half way to an
> infrstructure for DB migrations, no? Especially if it could be
> combined with some kind of Migratable behaviour?
>
> Searches for Cake migrations don't reveal any offical ones, and I
> don't want to work with YAML etc.
>
> Are they any steps towards offical cake migrations features, I'd be
> interested in taking a look, even if they're not very advanced...?

[Dr. Tarique Sani]

On Sun, May 18, 2008 at 4:48 PM, joelmoss <joel-r2NuqecuH8Uk+I/***@public.gmane.org> wrote:

>
> cannot roll back your changes. There is an unofficial Migrations shell
> available at http://code.google.com/p/cakephp-migrations/, which is a
> full DB migrations system. I am hoping to see this being introduced in
> the next version of Cake (v2.0).


FWIW - Will use this when it has no pear dependency and does not use yaml -
though introduction of query was a nice step.

Hmmmm... some day I just might hack the schema shell to be truly migrations

Tarique

--
=============================================================
Cheesecake-Photoblog: http://cheesecake-photoblog.org
PHP for E-Biz: http://sanisoft.com

[Dardo Sordi Bogado]

> Hmmmm... some day I just might hack the schema shell to be truly migrations

I hope you don't, they are just great the way there are.

The cake Schemas are far better than migrations, because they are a
different concept.


First we should get the concept behind cake's Schemas and how they
are different from Rail's migrations.


The Schema (capitalized refers to cake's Schema) is a way to describe
the current state of the database, whether a migration is a way to define
a change to it's state.

Think of Schemas as snapshots of the db and migrations as a patch.

Schemas in cake works like git (the scm I use), recording the full state
every time, instead of just a delta (like svn does), this brings a lot
of flexibility and power allowing for example:

* To let the SCM do the hard work of schema version control, merging, etc.
* To have a unique place where to find the current database structure
that the application needs to run.
* Using any tool of your choice for doing the changes to the database.


Having this in mind, we can say that Schemas are a way to keep with the
application code a description of the database structure.


Think you get a fresh checkout of the app to work with, next thing
you need is the database for the application.

Here is where cake schema shell really shines. It lets you synchronize
in both ways the Schema and the database.


Last thing to keep in mind is the difference in the workflows:

Migrations:
-----------

1. Create a migration in the stupid language that they work (no matter
what it is, you always end hating it).
2. Run the migration to update the DB.
3. Go and hack your code (test it also if you feel like doing so).
4. Then commit to the SCM.
5. Other developers checkout your changes and run migrations.

Now, if you are in a truly parallel development scenario this doesn't
works well.
Other developers have introduced changes in the schema and now you
have to realize
what migrations and in what order you must run to get it working.


Schemas:
--------

1. Do the changes to the DB with your tool of choice.
2. Go and hack your code (test it also if you feel like doing so).
3. Update the Schema (using cake schema shell)
4. Then commit to the SCM (code an schema).
5. Other developers update and merge (mostly gets done by the SCM) the
changes to code an schema.
6. Then they just synchronize their DB using the schema shell.

Every one on sync and happy!


Cake Schema is superior in various technical aspects to migrations,
but the key difference is in their filosofy.


Regards,
- Dardo Sordi.

[Keith]

Dardo can you elaborate on why schemas are better than migrations in
iterative development?

Just to address some issues here:

1. Migrations as "Patches" - Migrations CAN be patches. Migrations
are not patches though. For example, in Joel's system you can most
certainly create a migration supporting a model that is complete. In
many cases models won't need tweaks, but in some cases, particularly
in multi-developer environments, having the ability to create patches
is critical.

2. Migrations are incomplete - Migrations CAN be incomplete, but when
migrations are run in sequence they are as complete as a Schema.

Git allows you to keep a local copy of the SCM in which you can create
your own revisions and then sync it later. Many developers, in fact I
would suggest most, do not use Git yet. I would argue that the
majority of folks are on some flavor of SVN or CVS. In these cases
there is no local revision only the revision you have to commit.

Let me propose the counter-argument to why migrations are superior to
Schema. I think this is a debate that could be endless, but in terms
of commonly accepted practice in interative agile development there
are many more proponents of the migration model than the Schema model.

1. Migrations are iterative.

When you're developing it is useful to back out model changes if they
do not work. With Schema, you're working directly with the SQL which
is not necessarily database agnostic. Once you back out that change
you have no way to return to any other state unless you check out a
file from your SCM.

In this way your iterative development model is supported step-by-step
with your migrations. You can track and move your application to any
state you need without needing to check out full blown schemas.

2. Migrations are multi-developer friendly.

Migrations are iterative, so one developer's work will not overwrite
another developer's work. In the Schema model you've got multiple
developers committing their latest schema and relying on the SCM to
stitch the changes into the proper order. Migrations also quickly
allow developers to review specific database changes without needing
to review a single large file and finding the changes.

3. Migrations allow easier rollout

Let's say you need to roll out a single feature. In a migration you
just rollout that migration on your production environment with your
code deploy and you're set. In a Schema environemnt you need to
backup your database, rollout the new schema, restore the data and
you're good to go. While database backups should be a part of any
production environment rollout, having to backup / restore for even
minor database changes can be tiresome particularly when you're just
trying to fix a single bug in a production application.

4. Migrations have a reputable body or work behind them:

http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html
http://www.oreillynet.com/pub/a/ruby/2007/05/17/cookin-with-ruby-on-rails---may.html
http://www.ibm.com/developerworks/web/library/j-cb08156.html

While I think there are many ways to handle database schemas, the
migration model is currently the best of breed model on the market.
If multi-developer iterative design is the new model for application
development then there is no reason to avoid migrations. Joel's work
has been ongoing and his latest efforts are most definitely worth a
look. His migration model should make it into Cake 2.0 if not sooner
because of the value it adds to the core set of console tools
available with cakePHP.

Thank you to Dardo for posting his commentary about Schema because it
got me thinking about why I prefer migrations. Hopefully between his
well thought out argument and my counter-point cakePHP developers will
have a background to make a choice on what will work best for them.

On May 18, 11:02 am, "Dardo Sordi Bogado" <dardoso...-***@public.gmane.org>
wrote:
> > Hmmmm... some day I just might hack the schema shell to be truly migrations
>
> I hope you don't, they are just great the way there are.
>
> The cake Schemas are far better than migrations, because they are a
> different concept.
>
> First we should get the concept behind cake's Schemas and how they
> are different from Rail's migrations.
>
> The Schema (capitalized refers to cake's Schema) is a way to describe
> the current state of the database, whether a migration is a way to define
> a change to it's state.
>
> Think of Schemas as snapshots of the db and migrations as a patch.
>
> Schemas in cake works like git (the scm I use), recording the full state
> every time, instead of just a delta (like svn does), this brings a lot
> of flexibility and power allowing for example:
>
> * To let the SCM do the hard work of schema version control, merging, etc.
> * To have a unique place where to find the current database structure
> that the application needs to run.
> * Using any tool of your choice for doing the changes to the database.
>
> Having this in mind, we can say that Schemas are a way to keep with the
> application code a description of the database structure.
>
> Think you get a fresh checkout of the app to work with, next thing
> you need is the database for the application.
>
> Here is where cake schema shell really shines. It lets you synchronize
> in both ways the Schema and the database.
>
> Last thing to keep in mind is the difference in the workflows:
>
> Migrations:
> -----------
>
> 1. Create a migration in the stupid language that they work (no matter
> what it is, you always end hating it).
> 2. Run the migration to update the DB.
> 3. Go and hack your code (test it also if you feel like doing so).
> 4. Then commit to the SCM.
> 5. Other developers checkout your changes and run migrations.
>
> Now, if you are in a truly parallel development scenario this doesn't
> works well.
> Other developers have introduced changes in the schema and now you
> have to realize
> what migrations and in what order you must run to get it working.
>
> Schemas:
> --------
>
> 1. Do the changes to the DB with your tool of choice.
> 2. Go and hack your code (test it also if you feel like doing so).
> 3. Update the Schema (using cake schema shell)
> 4. Then commit to the SCM (code an schema).
> 5. Other developers update and merge (mostly gets done by the SCM) the
> changes to code an schema.
> 6. Then they just synchronize their DB using the schema shell.
>
> Every one on sync and happy!
>
> Cake Schema is superior in various technical aspects to migrations,
> but the key difference is in their filosofy.
>
> Regards,
> - Dardo Sordi.

[Dardo Sordi Bogado]

> Dardo can you elaborate on why schemas are better than migrations in
> iterative development?

I will try.

> Just to address some issues here:
>
> 1. Migrations as "Patches" - Migrations CAN be patches. Migrations
> are not patches though. For example, in Joel's system you can most
> certainly create a migration supporting a model that is complete. In
> many cases models won't need tweaks, but in some cases, particularly
> in multi-developer environments, having the ability to create patches
> is critical.

Yes, and Cake Schemas are extremely useful in that multi developer
iterative environment you mention.

> 2. Migrations are incomplete - Migrations CAN be incomplete, but when
> migrations are run in sequence they are as complete as a Schema.

Migrations can be derivated from two schemas (previous-next), and that
is exactly what cake schema shell does. It compares the schema.php to
the database schema and let you any.

> Git allows you to keep a local copy of the SCM in which you can create
> your own revisions and then sync it later. Many developers, in fact I
> would suggest most, do not use Git yet. I would argue that the
> majority of folks are on some flavor of SVN or CVS. In these cases
> there is no local revision only the revision you have to commit.

Yes, but not quite relevant. I was comparing the philosophy of storing
a sequence of deltas to storing the full state every time (which I
think is best).

> Let me propose the counter-argument to why migrations are superior to
> Schema. I think this is a debate that could be endless, but in terms
> of commonly accepted practice in interative agile development there
> are many more proponents of the migration model than the Schema model.

Is that an ad hominem argument?


> 1. Migrations are iterative.
>
> When you're developing it is useful to back out model changes if they
> do not work. With Schema, you're working directly with the SQL which
> is not necessarily database agnostic. Once you back out that change
> you have no way to return to any other state unless you check out a
> file from your SCM.

In my proposed workflow, you change the database with the tool that
you like the most, and then update the schema file using the cake
shell.

> In this way your iterative development model is supported step-by-step
> with your migrations. You can track and move your application to any
> state you need without needing to check out full blown schemas.

I don't see the problem in having to "checking out full blown
schemas", but again why you want a version of the database different
from what your application expects? Well there are some cases, while
testing a setup for example but that is an edge case.

> 2. Migrations are multi-developer friendly.
>
> Migrations are iterative, so one developer's work will not overwrite
> another developer's work. In the Schema model you've got multiple
> developers committing their latest schema and relying on the SCM to
> stitch the changes into the proper order. Migrations also quickly
> allow developers to review specific database changes without needing
> to review a single large file and finding the changes.

Nope, migrations aren't multi developer friendly. What happens if two
developers doing work in parallel do conflicting changes to the
database?

In the schema model, that situation is detected by the scm (during the
merge) and human is forced to solve the conflict.

In the migration model, where their are in different files, the
conflict goes unnoticed.

> 3. Migrations allow easier rollout
>
> Let's say you need to roll out a single feature. In a migration you
> just rollout that migration on your production environment with your
> code deploy and you're set. In a Schema environemnt you need to
> backup your database, rollout the new schema, restore the data and
> you're good to go. While database backups should be a part of any
> production environment rollout, having to backup / restore for even
> minor database changes can be tiresome particularly when you're just
> trying to fix a single bug in a production application.

You are talking about a SQL dump and I'm talking about cake schemas.

> 4. Migrations have a reputable body or work behind them:
>
> http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html
> http://www.oreillynet.com/pub/a/ruby/2007/05/17/cookin-with-ruby-on-rails---may.html
> http://www.ibm.com/developerworks/web/library/j-cb08156.html

Another ad hominem argument? Well behind cake schemas is cake core team.

> While I think there are many ways to handle database schemas, the
> migration model is currently the best of breed model on the market.
> If multi-developer iterative design is the new model for application
> development then there is no reason to avoid migrations.

Have you tried to use and understand cake schema?

> Joel's work
> has been ongoing and his latest efforts are most definitely worth a
> look. His migration model should make it into Cake 2.0 if not sooner
> because of the value it adds to the core set of console tools
> available with cakePHP.

I liked Joel work, and used it before cake's schema. Then got all kind
of conflicts when doing parallel work, and realized I needed something
that allows me to do it well, decided to give cake schema a try and
discovered how wonderful they are.

> Thank you to Dardo for posting his commentary about Schema because it
> got me thinking about why I prefer migrations. Hopefully between his
> well thought out argument and my counter-point cakePHP developers will
> have a background to make a choice on what will work best for them.

You are welcome, but I think cake core team is smart enough to see why
schema (as implemented in cake) is better than migrations, if don't,
Why they go throught all the trouble of writing it to just discard it
later in favor of a previously well known technology?

- Dardo Sordi.

> On May 18, 11:02 am, "Dardo Sordi Bogado" <dardoso...-***@public.gmane.org>
> wrote:
>> > Hmmmm... some day I just might hack the schema shell to be truly migrations
>>
>> I hope you don't, they are just great the way there are.
>>
>> The cake Schemas are far better than migrations, because they are a
>> different concept.
>>
>> First we should get the concept behind cake's Schemas and how they
>> are different from Rail's migrations.
>>
>> The Schema (capitalized refers to cake's Schema) is a way to describe
>> the current state of the database, whether a migration is a way to define
>> a change to it's state.
>>
>> Think of Schemas as snapshots of the db and migrations as a patch.
>>
>> Schemas in cake works like git (the scm I use), recording the full state
>> every time, instead of just a delta (like svn does), this brings a lot
>> of flexibility and power allowing for example:
>>
>> * To let the SCM do the hard work of schema version control, merging, etc.
>> * To have a unique place where to find the current database structure
>> that the application needs to run.
>> * Using any tool of your choice for doing the changes to the database.
>>
>> Having this in mind, we can say that Schemas are a way to keep with the
>> application code a description of the database structure.
>>
>> Think you get a fresh checkout of the app to work with, next thing
>> you need is the database for the application.
>>
>> Here is where cake schema shell really shines. It lets you synchronize
>> in both ways the Schema and the database.
>>
>> Last thing to keep in mind is the difference in the workflows:
>>
>> Migrations:
>> -----------
>>
>> 1. Create a migration in the stupid language that they work (no matter
>> what it is, you always end hating it).
>> 2. Run the migration to update the DB.
>> 3. Go and hack your code (test it also if you feel like doing so).
>> 4. Then commit to the SCM.
>> 5. Other developers checkout your changes and run migrations.
>>
>> Now, if you are in a truly parallel development scenario this doesn't
>> works well.
>> Other developers have introduced changes in the schema and now you
>> have to realize
>> what migrations and in what order you must run to get it working.
>>
>> Schemas:
>> --------
>>
>> 1. Do the changes to the DB with your tool of choice.
>> 2. Go and hack your code (test it also if you feel like doing so).
>> 3. Update the Schema (using cake schema shell)
>> 4. Then commit to the SCM (code an schema).
>> 5. Other developers update and merge (mostly gets done by the SCM) the
>> changes to code an schema.
>> 6. Then they just synchronize their DB using the schema shell.
>>
>> Every one on sync and happy!
>>
>> Cake Schema is superior in various technical aspects to migrations,
>> but the key difference is in their filosofy.
>>
>> Regards,
>> - Dardo Sordi.
> >
>

[Dr. Tarique Sani]

On Sun, May 18, 2008 at 8:32 PM, Dardo Sordi Bogado <dardosordi-***@public.gmane.org>
wrote:

>
> > Hmmmm... some day I just might hack the schema shell to be truly
> migrations
>
> I hope you don't, they are just great the way there are.



Hope all you want! when I want to I will :)



> The cake Schemas are far better than migrations, because they are a
> different concept.


If I agree that the concept is different then you have wasted time in
comparing apples to oranges

Migrations *don't have to be* written in YAML - this is one of the prime
things which I don't like with Joel's implementation.

Other than that I agree with what Keith has written.

Cheers
Tarique


--
=============================================================
Cheesecake-Photoblog: http://cheesecake-photoblog.org
PHP for E-Biz: http://sanisoft.com

[joelmoss]

Well guys, I really found your comments very interesting, and both of
you raised valid points.t I don't think I will comment on the Schema
vs Migrations debate too much, other than to say that Cake's Schema
shell is different to Migrations, but they are still there to achieve
the same purpose; which is to manage your database. And when managing
something, the tool being used needs to be as flexible and as powerful
as possible. At the moment, Schema is very limited as to what it can
do.

Keith really nailed all the points on the head, better than I ever
could. In fact Keith, would you mind if I used your comments as part
of a blog post on http://developingwithstyle.com?

> FWIW - Will use this when it has no pear dependency and does not use yaml

Well, you will be happy to know that the next version of Migrations
will support PHP arrays in migrations files, as well as YAML. So you
will have the choice. Also, MDB2 is being dumped in favour of a
DataDict (http://phplens.com/lens/adodb/docs-datadict.htm) which does
not rely on PEAR, and is much smaller.

[Dr. Tarique Sani]

On Mon, May 19, 2008 at 2:08 PM, joelmoss <joel-r2NuqecuH8Uk+I/***@public.gmane.org> wrote:

> > FWIW - Will use this when it has no pear dependency and does not use yaml
>
> Well, you will be happy to know that the next version of Migrations
> will support PHP arrays in migrations files, as well as YAML. So you
> will have the choice. Also, MDB2 is being dumped in favour of a
> DataDict (http://phplens.com/lens/adodb/docs-datadict.htm) which does
> not rely on PEAR, and is much smaller.



Hurrah for you!

But is using DataDict needed? That more or less ensures that we will never
see your migrations in CakePHP core

Having something more native cake will be better - take a look at the Schema
code lots of stuff which you can use.


HTH

Tarique

--
=============================================================
Cheesecake-Photoblog: http://cheesecake-photoblog.org
PHP for E-Biz: http://sanisoft.com

[the_woodsman]

> Cake currently has a migrations-like schema shell, but it only allows
> you to create tables. You cannot make changes to existing tables, and
> cannot roll back your changes.

Joel, from looking at the blog post mentioned here (http://cakebaker.
42dh.com/2008/04/13/migrations-the-cakephp-way/), you can make changes
to existing tables
"./cake schema run update ..." .

If I get the jist right, the only thing lacking for these Schema
things to support RoR style migrations is:
- rollback (which seems partly implemented in the test suite, i.e
tables get dropped)
- logic to determine if updates or creates need to be performed (can't
be too difficult, as it appears tables are already diffed by the
update logic)

Surely these are so close it'd be better to extend these to meet the
needs of Migrations, rather than have something completely seperate?






On May 19, 10:14 am, "Dr. Tarique Sani" <tariques...-***@public.gmane.org> wrote:
> On Mon, May 19, 2008 at 2:08 PM, joelmoss <j...-r2NuqecuH8Uk+I/***@public.gmane.org> wrote:
> > > FWIW - Will use this when it has no pear dependency and does not use yaml
>
> > Well, you will be happy to know that the next version of Migrations
> > will support PHP arrays in migrations files, as well as YAML. So you
> > will have the choice. Also, MDB2 is being dumped in favour of a
> > DataDict (http://phplens.com/lens/adodb/docs-datadict.htm) which does
> > not rely on PEAR, and is much smaller.
>
> Hurrah for you!
>
> But is using DataDict needed? That more or less ensures that we will never
> see your migrations in CakePHP core
>
> Having something more native cake will be better - take a look at the Schema
> code lots of stuff which you can use.
>
> HTH
>
> Tarique
>
> --
> =============================================================
> Cheesecake-Photoblog:http://cheesecake-photoblog.org
> PHP for E-Biz:http://sanisoft.com
> =============================================================

[Dardo Sordi Bogado]

>> The cake Schemas are far better than migrations, because they are a
>> different concept.
>
> If I agree that the concept is different then you have wasted time in
> comparing apples to oranges

As they are different approaches to solve the same problem I can compare them.

> Migrations *don't have to be* written in YAML - this is one of the prime
> things which I don't like with Joel's implementation.

I know, but, can you tell me in what language they are easy to write
and look pretty? Post an example please.

Regards,
- Dardo Sordi.

> Other than that I agree with what Keith has written.
>
> Cheers
> Tarique
>
>
> --
> =============================================================
> Cheesecake-Photoblog: http://cheesecake-photoblog.org
> PHP for E-Biz: http://sanisoft.com
> =============================================================
> >
>

[Keith]

@ Dardo

The goal of my post was not to discredit your argument or you as you
suggest multiple times (ad hominem argument). I thought you wrote a
well thought out argument in favor of using Cake's built in Schema
which I stated in my post. I will continue to argue that your
provided workflow and associated argument are the essential points in
favor of Schema when people are looking for justification about it.

I would, however, suggest you read through the articles that I posted
as some of the things you noted in your line-by-line commentary are
addressed by people far more qualified to comment than I. When
writing about the differences I did due dilligence to understand the
benefits of cakePHP's built in Schema tool. I even looked for outside
commentary about it and as far as I could tell it is something that
has some similarities from practices in the Java world. So far, you
are the definitive voice on the subject in the CakePHP world!

@ Joel

I'm actually going to throw my summary into my blog and do not mind if
you put it into your blog as well. It is something that Dardo's post
got me thinking about. What started as a quick response turned into
something I too wouldn't mind using. I'm thrilled you'd want to use
it that way.

---

The bottom line is this: If CakePHP's Schema is working for you then
it should absolutely be the tool / approach you use. It is worthwhile
to mention that if it does not work for you, Joel has created an
alternative system that may be a better fit.



On May 19, 7:45 am, "Dardo Sordi Bogado" <dardoso...-***@public.gmane.org> wrote:
> >> The cake Schemas are far better than migrations, because they are a
> >> different concept.
>
> > If I agree that the concept is different then you have wasted time in
> > comparing apples to oranges
>
> As they are different approaches to solve the same problem I can compare them.
>
> > Migrations *don't have to be* written in YAML - this is one of the prime
> > things which I don't like with Joel's implementation.
>
> I know, but, can you tell me in what language they are easy to write
> and look pretty? Post an example please.
>
> Regards,
> - Dardo Sordi.
>
>
>
> > Other than that I agree with what Keith has written.
>
> > Cheers
> > Tarique
>
> > --
> > =============================================================
> > Cheesecake-Photoblog:http://cheesecake-photoblog.org
> > PHP for E-Biz:http://sanisoft.com
> > =============================================================- Hide quoted text -
>
> - Show quoted text -

[Dardo Sordi Bogado]

> The goal of my post was not to discredit your argument or you as you
> suggest multiple times (ad hominem argument).

I wasn't saying that you tried to discredit me, but to argument in
favor of migration with

> Migrations have a reputable body or work behind them

seems like an ad hominem argument to me.

> I thought you wrote a
> well thought out argument in favor of using Cake's built in Schema
> which I stated in my post. I will continue to argue that your
> provided workflow and associated argument are the essential points in
> favor of Schema when people are looking for justification about it.

Well, I've just wanted to share my experience with both, migrations
and cake schema (something I found to be very different from the
things in the java world you mention, but I'm not a java programmer).
For me, cake schema worked better than migrations in my working
enviroment, with the tools I've been using.

> I would, however, suggest you read through the articles that I posted
> as some of the things you noted in your line-by-line commentary are
> addressed by people far more qualified to comment than I. When
> writing about the differences I did due dilligence to understand the
> benefits of cakePHP's built in Schema tool. I even looked for outside
> commentary about it and as far as I could tell it is something that
> has some similarities from practices in the Java world.

I've read them, but it didn't answer what Joel is adressing here:

http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/

and what happens when two or more migrations conflicts.


> So far, you
> are the definitive voice on the subject in the CakePHP world!

I've didn't noticed it, isn't anyone else using the Cake schema shell?
If that is the case, they are missing a great tool.


As a final note, while re reading what I've wrote I've noticed that it
was too bad spelled and worded (actually it seems like I'm writing
using my elbows) sorry for that. Also, I didn't want to sound too
hash, but in the final result the was tone too grumpy (maybe I'm
reading this list too much, jaja).

Cheers,
- Dardo Sordi.

[David Christopher Zentgraf]

On 20 May 2008, at 08:21, Dardo Sordi Bogado wrote:

> I've didn't noticed it, isn't anyone else using the Cake schema shell?
> If that is the case, they are missing a great tool.

Speaking for me personally, I'm not using schema because there's very
little documentation to be found. This thread seems like the most
informative thing I've read about the whole topic so far (thanks both
for your posts). I've played around with schema once just looking at
the provided ones, but couldn't figure out how to create multiple
UNIQUE indexes and got frustrated.

You've got me interested in the whole concept again, but I really wish
there were some in-depth articles about schema. *wink*wink*nudge*nudge*

Chrs,
Dav

[Keith]

On May 19, 7:21 pm, "Dardo Sordi Bogado" <dardoso...-***@public.gmane.org> wrote:
> I've read them, but it didn't answer what Joel is adressing here:
>
> http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/
>
> and what happens when two or more migrations conflicts.

He addresses the answer in that post. You don't label the migration
sequentially. You label it based on UTC timestamp as the race
condition where 2 developers generate a migration at exactly the same
moment is highly unlikely. Rails 2.1 is going that way (http://
railscasts.com/episodes/107).

- Keith

[Dardo Sordi Bogado]

> He addresses the answer in that post. You don't label the migration
> sequentially. You label it based on UTC timestamp as the race
> condition where 2 developers generate a migration at exactly the same
> moment is highly unlikely. Rails 2.1 is going that way (http://
> railscasts.com/episodes/107).

If you are talking about a parallel development environment, a change
made forward in time doesn't necessarily should be ordered after
others that happened before it but based on the same revision.

C --- D
/ \
A---B------E-------*--- Should migration E be between C and D ? Can we
say that based on the timestamp?

You'll see, some times order matters.

To me there seem to be 3 possible orders: C-E-D, C-D-E, E-C-D.

- Dardo Sordi.


> - Keith
> >
>

[joelmoss]

> To me there seem to be 3 possible orders: C-E-D, C-D-E, E-C-D.

Then in that edge case, you simply modify either migrations
themselves, or the timestamp, so that the order is correct.

One of the best things about Migrations, is that they are fully
incremental, and each one can be rolled back very easily.

It's all sounding to me that this is all about preference. All I know
is that the core team plan on reviewing Schema and Migrations after
1.2 is released, to see if there is an common ground. I certainly hope
we can do something, as there is a lot of overlay between the two. But
if Migrations is not used, then I will simply continue to use and
develop it as third party add-on for Cake.

FYI: Migrations v4.0 Beta has just been released ->
http://developingwithstyle.com/2008/05/20/cakephp-migrations-v40-beta/

[Aaron Shafovaloff]

It'd be great if schema arrays could include an "old_name" field, so
that CakePHP could not only create fields and create tables, but
rename them. In other words, something like:

class BlogSchema extends CakeSchema {
public $posts = array(
'id' => array('type' => 'integer', 'null' => false, 'default'
=> NULL, 'key' => 'primary'),
'title' => array('type' => 'string', 'null' => false, 'length'
=> 100, 'old_name' => 'name'),
'content' => array('type' => 'text', 'null' => false,
'old_name' => 'body'),
'indexes' => array('PRIMARY' => array('column' => 'id',
'unique' => 1))
);
}

Get my drift? If we could somehow tell Cake the history of a
particular table or field, it seems like we could get the best of both
worlds.

[Gwoo]

Ok, since I wrote CakeSchema, I suppose I could elaborate on some of
its uses. I think most people have understood what it was intended to
do, though I have not thoroughly read all of the previous messages.

The basic idea behind CakeSchema is to have a complete snapshot of
your application's data structure at a given point in time. With this
in mind it would probably be wise to add a timestamp option to go
along with the version number option. In any case, if you are using a
proper SCM you do not even need to use the snapshots. CakeSchema can
work for a variety of workflows and situations.

One possible workflow follows:
1) Design your database with DbDesigner or some other gui.
2) Export the sql for your preferred database server
3) Import the sql via your database GUI
4) Scaffold your application
5) make any desired adjustments
6) cake schema generate
7) use the before and after callbacks to populate some initial data
8) commit to svn

Voila. You have the first version of your application ready. Let other
developers use "cake schema run create" so they can start from the
same point.

But now I need to make some changes.....
1) Open up your database GUI
2) Make all the needed changes
3) cake schema generate
4) commit to svn

Now all someone has to do is "cake schema run update" and they have
all the latest changes. If a new developer comes into the picture then
they can create. If you want to see the difference between two schemas
you can do a dry run through the console or diff the revisions.

There are many other possibilities. I have heard of people who
actually like creating the schema in php with their favorite text
editor. In addition, since each schema is a class that extends
CakeSchema and is loaded through Cake you have all the advantages of
the framework to do whatever your imagination may desire. For example,
you may want to provide a simple web based installation for you
application. Well, with a few lines of code you could make that
happen.

In general, I think CakeSchema covers many use cases and as always,
enhancement tickets are more than welcome.

Bake on.

[Dardo Sordi Bogado]

> For example,
> you may want to provide a simple web based installation for you
> application. Well, with a few lines of code you could make that
> happen.

I'm already doing that (borrowed the code from the schema shell).

Schema rocks!

[Dardo Sordi Bogado]

On Tue, May 20, 2008 at 5:41 PM, Aaron Shafovaloff <aaronshaf-***@public.gmane.org> wrote:
>
> It'd be great if schema arrays could include an "old_name" field, so
> that CakePHP could not only create fields and create tables, but
> rename them.
> Get my drift? If we could somehow tell Cake the history of a
> particular table or field, it seems like we could get the best of both
> worlds.

Yes, handling renames is a tricky business.

> >
>

[joelmoss]

On May 21, 1:25 am, Gwoo <gwoo.cake...-***@public.gmane.org> wrote:
> Now all someone has to do is "cake schema run update" and they have
> all the latest changes. If a new developer comes into the picture then
> they can create. If you want to see the difference between two schemas
> you can do a dry run through the console or diff the revisions.

Gwoo, I got a few questions...

Am I right in saying, that if I make changes to a shema file and run
that, it runs the entire schema again? Wouldn't that overwrite your
existing DB tables?
Does Schema support all DB backends right now?
Does Schema allow you to rename/modify/drop columns, or just create
tables and columns?

I just want to find out what the limitation of the Schema shell is, if
there are any.

Joel

[Dr. Tarique Sani]

On Wed, May 21, 2008 at 1:51 PM, joelmoss <joel-sRGVn2TPT5Nu8n0NSpuEMFaTQe2KTcn/@public.gmane.org> wrote:

> Gwoo, I got a few questions...


Hey even I can answer that ;)

>
>
> Am I right in saying, that if I make changes to a shema file and run
> that, it runs the entire schema again? Wouldn't that overwrite your
> existing DB tables?


No! Schema is an entire snapshot *but* only the changes needed will be run


>
> Does Schema support all DB backends right now?


I don't know about other DB backends but Schema does need work (does not
store column length etc;)


> Does Schema allow you to rename/modify/drop columns, or just create
> tables and columns?
>

Allows you to drop and add columns - rename is not supported.

I just want to find out what the limitation of the Schema shell is, if
> there are any.


We need renaming, column meta data, fixtures and some callbacks which can
run on fixtures.

So, like I was suggesting, making Schema have more features and giving it an
option to run a migration like scenario will be great. We are almost there
and I don't think any changes will be needed to the current Schema workflow
- lets have best of both worlds

Cheers
Tarique

--
=============================================================
Cheesecake-Photoblog: http://cheesecake-photoblog.org
PHP for E-Biz: http://sanisoft.com
=============================================================

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php-/***@public.gmane.org
To unsubscribe from this group, send email to cake-php-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

[Dardo Sordi Bogado]

> I don't know about other DB backends but Schema does need work (does not
> store column length etc;)

It does store them, almost for me (PHP5, MySQL 5, latest Cake from SVN):

'username' => array('type'=>'string', 'null' => false, 'default' =>
NULL, 'key' => 'unique'), <--- here not, varchar(255)
'password' => array('type'=>'string', 'null' => false, 'default' =>
NULL, 'length' => 40), <--- there yes, varchar(40)

> We need renaming, column meta data, fixtures and some callbacks which can
> run on fixtures.

I think they have callbacks:

function before($event = array()) {
return true;
}

function after($event = array()) {
}


> So, like I was suggesting, making Schema have more features and giving it an
> option to run a migration like scenario will be great. We are almost there
> and I don't think any changes will be needed to the current Schema workflow
> - lets have best of both worlds

That would be great.

Regards
- Dardo Sordi.

> Cheers
> Tarique
>
> --
> =============================================================
> Cheesecake-Photoblog: http://cheesecake-photoblog.org
> PHP for E-Biz: http://sanisoft.com
> =============================================================
> >
>

[Dardo Sordi Bogado]

>> To me there seem to be 3 possible orders: C-E-D, C-D-E, E-C-D.
>
> Then in that edge case, you simply modify either migrations
> themselves, or the timestamp, so that the order is correct.

I don't think that two developers working in parallel can be
considered and edge case, and being that a common case in my workplace
is that we decided to switch to cake schema (after I stoped of pulling
my hair and got them working), since them we are a happy team.

> One of the best things about Migrations, is that they are fully
> incremental, and each one can be rolled back very easily.

I do agree, doing changes in a incremental (and atomic) way really
helps to do agile development.

> It's all sounding to me that this is all about preference. All I know
> is that the core team plan on reviewing Schema and Migrations after
> 1.2 is released, to see if there is an common ground. I certainly hope
> we can do something, as there is a lot of overlay between the two.

That would be great, there are a lot of place for improvement an
innovation in the field.

> But
> if Migrations is not used, then I will simply continue to use and
> develop it as third party add-on for Cake.

Don't know what to say, but I get used to split emails in chunks.... :O

Cheers,
- Dardo Sordi.

> FYI: Migrations v4.0 Beta has just been released ->
> http://developingwithstyle.com/2008/05/20/cakephp-migrations-v40-beta/
> >
>

[Keith]

Well here's the deal...

I played around with Schema a bit last night. I have only a few
issues with it in practice:

1. It doesn't handle autoincrement correctly in the latest nightly
build when you generate a schema from an existing table.
2. The downloadable 1.2 beta has major bugs in it like an incorrect
refernce to the string tokenizer so newbies may not even be fully
exploring Schema in the console!

Aside from that...

You can basically use the schema tool as migrations.

You can create Schema.php and then create Schema_2.php and so on.
You're then able to note version numbers you want to "migrate" to in
the console. So far as I can tell, it has a lot in common with the
old way that migrations worked in Rails 2.0.

Given that this is now how Schema works I think it may be worthwhile
to investigate different ways to use Schema. Dardo has one
methodology that he's been evangelizing in this thread. I wonder if
we could get phpNut or someone on the core team more familiar with
Schema's development to comment on the design decisions behind it
given the functionality that hasn't been talked about on here. I'll
probably put together a little tutorial or something for my blog once
I get everything all worked out on my own, but this was news to me!

[Dardo Sordi Bogado]

> Well here's the deal...
>
> I played around with Schema a bit last night.

I'm really happy now :P

> I have only a few
> issues with it in practice:

> 1. It doesn't handle autoincrement correctly in the latest nightly
> build when you generate a schema from an existing table.

It's working for me in the rev 6990 in mysql.

> 2. The downloadable 1.2 beta has major bugs in it like an incorrect
> refernce to the string tokenizer so newbies may not even be fully
> exploring Schema in the console!

Well, I hope stable is coming soon.

> Aside from that...
>
> You can basically use the schema tool as migrations.

In that case I think Joel's migrations are better, but I always talk
about my personal experience... YMMV

> You can create Schema.php and then create Schema_2.php and so on.
> You're then able to note version numbers you want to "migrate" to in
> the console. So far as I can tell, it has a lot in common with the
> old way that migrations worked in Rails 2.0.
>
> Given that this is now how Schema works I think it may be worthwhile
> to investigate different ways to use Schema.

Sure, there are many ways of using a tool.

> Dardo has one
> methodology that he's been evangelizing in this thread.

"A voice of one calling in the desert" comes now to my mind, :P

> I wonder if
> we could get phpNut or someone on the core team more familiar with
> Schema's development to comment on the design decisions behind it
> given the functionality that hasn't been talked about on here.

That would be great.

> I'll
> probably put together a little tutorial or something for my blog once
> I get everything all worked out on my own, but this was news to me!

Looking forward to see it.

Regards,
- Dardo Sordi.