Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merging the feature branch migrations-from-cli in #158

Merged
merged 16 commits into from Mar 6, 2014
Merged

Merging the feature branch migrations-from-cli in #158

merged 16 commits into from Mar 6, 2014

Conversation

burzum
Copy link
Contributor

@burzum burzum commented Mar 6, 2014

No description provided.

josegonzalez and others added 16 commits December 23, 2013 05:10
This functionality only works when arguments are passed to the command `cake Migrations.migration generate`.

This commit adds the ability to perform commands such as the following:

    app/Console/cake Migrations.migration generate create_users id:primary_key name:string created modified

    app/Console/cake Migrations.migration generate alter_users name:string:index

    app/Console/cake Migrations.migration generate drop_users

    app/Console/cake Migrations.migration generate add_taxonomic_stuff_to_posts category:string tags:string

    app/Console/cake Migrations.migration generate remove_taxonomic_stuff_from_posts category tags

The above commands would:

- Create a users table with the fields [`id`, `name`, `created`, `modified`]. A single primary key index would exist on `id`, and the `created` and `modified` fields would default to `datetime`, as per CakePHP conventions. Since the type is specified on `name`, it is string.
- Add an index to the `name` column in the `users` table.
- Drop the users table.
- Add `category` and `tags` fields to the `posts` table.
- Remove `category` and `tags` fields from the `posts` table.

Due to the conventions, not all schema changes can be performed via these shell commands.

Migration Names can follow any of the following regices:

- *create_table* `/^(create)_(.*)/`: Creates the specified table
- *drop_table* `/^(drop)_(.*)/`: Drops the specified table. Ignores specified field arguments.
- *add_field* `/^(add)_.*_(?:to)_(.*)/`: Adds fields to the specified table
- *remove_field* `/^(remove)_.*_(?:from)_(.*)/`: Removes fields from the specified table
- *alter_table* `/^(alter)_(.*)/` : Alters the specified table. The *alter_table* command can be used as an alias for `create_table` and `add_field`.

Migration names are used as migration class names, and thus may collide with other migrations if the class names are not unique. In this case, it may be necessary to manually override the name at a later date, or simply change the name you are specifying.

Fields are verified via the following the following regular expression:

    /^(\w*)(?::(\w*))?(?::(\w*))?(?::(\w*))?/

They follow the format:

    field:fieldType:indexType:indexName

For instance, the following are all valid ways of specifying the primary key `id`:

- `id:primary_key`
- `id:primary_key:primary`
- `id:integer:primary`
- `id:integer:primary:ID_INDEX`

Field types are specific to the database connection in use specified by the `--connection` argument (`default` by default). Thus, valid `Postgres` field types include `inet` and `number`, while for `MySQL` the fieldType would be ignored.

There are some heuristics to choosing fieldtypes when left unspecified or set to an invalid value:

- `id`: *integer*
- `created`, `modified`, `updated`: *datetime*
- Default *string*

Lengths for certain columns are also defaulted:

- *string*: `255`
- *integer*: `11`
- *biginteger*: `20`
Cake standards expect true, false and null to be lowercase. The code was being generated correctly (lowercase), but was being asserted against an incorrect example (which used uppercase NULL)

Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
The test was failing due to the assertion on line 238, where it expected 'reset' => true to exist in the array - but there's no situation where that key/value is added, or needs to be added, in the code itself. Reset works, and asserting that 'version' => 0 is sufficient to test this.

Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
generate() method was 80+ lines and very hard to read. To break it up, I had to pass several params in by reference to each sub-method, which isn't ideal either, but still an improvement in terms of readability.

Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
…i arguments

Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
Get migrations from cli working and tested.
Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
Tests were failing on Travis only, due to a) database collation not being set, and b) there being no $default database config in the travis.yml file

Signed-off-by: Joshua Paling <joshua.paling@gmail.com>
jameswatts added a commit that referenced this pull request Mar 6, 2014
Merging the feature branch migrations-from-cli
@jameswatts jameswatts merged commit 4b7a224 into CakeDC:develop Mar 6, 2014
@jameswatts
Copy link
Contributor

Thank you!!!

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling f5d13c6 on burzum:develop into 54870f3 on CakeDC:develop.

deizel pushed a commit to deizel/cakedc-migrations that referenced this pull request Mar 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants