Git Product home page Git Product logo

ruckusing-migrations's Introduction

Introduction

Ruckusing is a framework written in PHP5 for generating and managing a set of "database migrations". Database migrations are declarative files which represent the state of a DB (its tables, columns, indexes, etc) at a particular state of time. By using database migrations, multiple developers can work on the same application and be guaranteed that the application is in a consistent state across all remote developer machines.

The idea of the framework was borrowed from the migration system built into Ruby on Rails. Any one who is familiar with Migrations in RoR will be immediately at home.

Build Status

Getting Started & Documentation

See the Wiki for the complete documentation on the migration methods supported and how to get started.

Databases Supported

  • Postgres
  • MySQL
  • Sqlite

Features

  • Portability: the migration files, which describe the tables, columns, indexes, etc to be created are themselves written in pure PHP5 which is then translated to the appropriate SQL at run-time. This allows one to transparently support any RDBMS with a single set of migration files (assuming there is an adapter for it, see below).

  • "rake" like support for basic tasks. The framework has a concept of "tasks" (in fact the primary focus of the framework, migrations, is just a plain task) which are just basic PHP5 classes which implement an interface. Tasks can be freely written and as long as they adhere to a specific naming convention and implement a specific interface, the framework will automatically register them and allow them to be executed.

  • The ability to go UP or DOWN to a specific migration state.

  • Code generator for generating skeleton migration files.

  • Support for module based migration directories where migrations files could be generated/run from specified module directories.

  • Out-of-the-box support for basic tasks like initializing the DB schema info table (db:setup), asking for the current version (db:version) and dumping the current schema (db:schema).

Limitations

  • PHP 5.2+ is a hard requirement. The framework employes extensive use of object-oriented features of PHP5. There are no plans to make the framework backwards compatible.

Configuration

  • Copy /path/to/ruckusing-migrations/config/database.inc.php to /path/to/mycodebase/ruckusing.conf.php and update the development key with your DB credentials:

type is one of pgsql, mysql, sqlite depending on your database, as well migrations_dir, db_dir, log_dir, ruckusing_base paths.

  • If you want to use module migration directories, Edit /path/to/mycodebase/ruckusing.conf.php and update migrations_dir like array('default' => '/default/path', 'module_name' => '/module/migration/path') paths.

  • Copy /path/to/ruckusing-migrations/ruckus.php to /path/to/mycodebase/ruckus.php.

Custom Tasks

All tasks in lib/Task are enabled by default. If you would like to implement custom tasks then you can specify the directory of your tasks in your over-ridden ruckusing.conf.php in the tasks_dir key:

# ruckusing.conf.php

return array(
 /* ... snip ... */,
 'tasks_dir' => RUCKUSING_WORKING_BASE . '/custom_tasks'
);

Generating Skeleton Migration files

From the top-level of your code base, run:

$ php ruckus.php db:generate create_users_table

Created OK
Created migration: 20121112163653_CreateUsersTable.php

Module migration directory example:

$ php ruckus.php db:generate create_items_table module=module_name

Created OK
Created migration: 20121112163653_CreateItemsTable.php

The generated file is in the migrations directory. Open up that file and you'll see it looks like:

class CreateUsersTable extends Ruckusing_Migration_Base {

	public function up() {

	}//up()

	public function down() {

	}//down()
}

All of the methods below are to be implemented in the up() and down() methods.

Environments

You can switch environments via the ENV command line argument. The default environtment is development.

To specify an additional environment add it to ruckusing.conf.php under the db key.

Running with a different environment:

$ ENV=test php db:migrate

Running Migrations

Run all pending migrations:

$ php ruckus.php db:migrate

Rollback the most recent migration:

$ php ruckus.php db:migrate VERSION=-1

Rollback to a specific migration (specify the timestamp in the filename of the migration to rollback to):

$ php ruckus.php db:migrate VERSION=20121114001742

Overview of the migration methods available

The available methods are (brief list below, with detailed usageg further down):

Database-level operations

  • create_database
  • drop_database

Table-level operations

  • create_table
  • drop_table
  • rename_table

Column-level operations

  • add_column
  • remove_column
  • rename_column
  • change_column
  • add_timestamps

Index-level operations

  • add_index
  • remove_index

Query execution

  • execute
  • select_one
  • select_all

Database-level Operations

There are two database-level operations, create_database and drop_database. Migrations that manipulate databases on this high of a level are used rarely.

Creating a new Database

This command is slightly useless since normally you would be running your migrations against an existing database (created and setup with whatever your traditional RDMBS creation methods are). However, if you wanted to create another database from a migration, this method is available:

Method Call: create_database

Parameters name : Name of the new database

Example:

    $this->create_database("my_project");

Removing a database

To completely remove a database and all of its tables (and data!).

Method Call: drop_database

Parameters name : Name of the existing database

Example:

    $this->drop_database("my_project");

This method is probably the most complex of all methods, but also one of the most widely used.

Method Call: create_table

Parameters

name : Name of the new table

options : (Optional) An associative array of options for creating the new table.

Supported option key/value pairs are:

id : Boolean - whether or not the framework should automatically generate a primary key. For MySQL the column will be called id and be of type integer with auto-incrementing.

options : A string representing finalization parameters that will be passed verbatim to the tail of the create table command. Often this is used to specify the storage engine for MySQL, e.g. 'options' => 'Engine=InnoDB'

Assumptions Ultimately this method delegates to the appropriate RDMBS adapter and the MySQL adapter makes some important assumptions about the structure of the table.

Table-level operations

The database migration framework offers a rich facility for creating, removing and renaming tables.

Creating tables

A call to $this->create_table(...) actually returns a TableDefinition object. This method of the framework is one of the very few which actually returns a result that you must interact with (as and end user).

The steps for creating a new table are:

  • Create the table with a name and any optional options and store the return value for later use:
    $users = $this->create_table("users");
  • Add columns to the table definition:
    $users->column("first_name", "string");
    $users->column("last_name", "string");
  • Call finish() to actually create the table with the definition and its columns:
    $users->finish();

By default, the table type will be what your database defaults too. To specify a different table type (e.g. InnoDB), pass a key of options into the $options array, e.g.

Example A: Create a new InnoDB table called users.

    $this->create_table('users', array('options' => 'Engine=InnoDB'));
  • This command also assumes that you want an id column. This column does not need to be specified, it will be auto-generated, unless explicitly told not to via the id key in $options array.

Example B: Create a new table called users but do not automatically make a primary key.

    $this->create_table('users', array('id' => false));

The primary key column will be created with attributes of int(11) unsigned auto_increment.

Example C: To specify your own primary key called 'guid':

    $t = $this->create_table('users', array('id' => false, 'options' => 'Engine=InnoDB'));
    $t->column('guid', 'string', array('primary_key' => true, 'limit' => 64));
    $t->finish();

Removing tables

Tables can be removed by using the drop_table method call. As might be expected, removing a table also removes all of its columns and any indexes.

Method Call: drop_table

Arguments:: table_name: The name of the table to remove.

Example:

   $this->drop_table("users");

Renaming tables

Tables can be renamed using the rename_table method.

Method Call: rename_table

Arguments:: table_name: The existing name of the table. new_name: The new name of the table.

Example:

   // rename from "users" to "people"
   $this->rename_table("users", "people");

Column-level operations

Adding a new column to a table

For the complete documentation on adding new columns, please see Adding Columns

Removing Columns

Removing a database column is very simple, but keep in mind that any index associated with that column will also be removed.

Method call: remove_column

Arguments table_name: The name of the table from which the column will be removed.

column_name: The column to be removed.

Example A:: Remove the age column from the users table.

    $this->remove_column("users", "age");

Renaming a column

Database columns can be renamed (assuming the underlying RDMBS/adapter supports it).

Method call: rename_column

Arguments: table_name: The name of table from which the column is to be renamed.

column_name: The existing name of the column.

new_column_name: The new name of the column.

Example A: From the users table, rename first_name to fname

    $this->rename_column("users", "first_name", "fname");

Modifying an existing column

The type, defaults or NULL support for existing columns can be modified. If you want to just rename a column then use the rename_column method. This method takes a generalized type for the column's type and also an array of options which affects the column definition. For the available types and options, see the documentation on adding new columns, AddingColumns.

Method Call: change_column

Arguments: table_name: The name of the table from which the column will be altered.

column_name: The name of the column to change.

type: The desired generalized type of the column.

options: (Optional) An associative array of options for the column definition.

Example A: From the users table, change the length of the first_name column to 128.

    $this->change_column("users", "first_name", "string", array('limit' => 128) );

Add timestamps columns

We often need colunmns to timestamp the created at and updated at operations. This convenient method is here to easily generate them for you.

Method Call:add_timestamps

Arguments: table_name: The name of the table to which the columns will be added

created_name: The desired of the created at column, be default created_at

updated_name: The desired of the updated at column, be default updated_at

Exemple A: Add timestamps columns to users table.

    $this->add_timestamps("users");

Exemple B: Add timestamps columns to users table with created and updated column names.

    $this->add_timestamps("users", "created", "updated");

Index-level operations

Indexes can be created and removed using the framework methods.

Adding a new index

Method Call: add_index

Arguments: table: The name of the table to add the index to.

column: The column to create the index on. If this is a string, then it is presumed to be the name of the column, and the index will be a single-column index. If it is an array, then it is presumed to be a list of columns name and the index will then be a multi-column index, on the columns specified.

options: (Optional) An associative array of options to control the index generation. Keys / Value pairs:

unique: values: true or false. Whether or not create a unique index for this column. Defaults to false.

name : values: user defined. The name of the index. If not specified, a default name will be generated based on the table and column name.

Known Issues / Workarounds: MySQL is currently limited to 64 characters for identifier names. When add_index is used without specifying the name of the index, Ruckusing will generate a suitable name based on the table name and the column(s) being index. For example, if there is a users table and an index is being generated on the username column then the generated index name would be: idx_users_username . If one is attempting to add a multi-column index then its very possible that the generated name would be longer than MySQL's limit of 64 characters. In such situations Ruckusing will raise an error suggesting you use a custom index name via the name option parameter. See Example C.

Example A: Create an index on the email column in the users table.

    $this->add_index("users", "email");

Example B: Create a unqiue index on the ssn column in the users table.

    $this->add_index("users", "ssn", array('unique' => true)));

Example C: Create an index on the blog_id column in the posts table, but specify a specific name for the index.

    $this->add_index("posts", "blog_id", array('name' => 'index_on_blog_id'));

Example D: Create a multi-column index on the email and ssn columns in the users table.

    $this->add_index("users", array('email', 'ssn') );

Removing an index

Easy enough. If the index was created using the sibling to this method (add_index) then one would need to just specify the same arguments to that method (but calling remove_index).

Method Call: remove_index

Arguments: table_name: The name of the table to remove the index from.

column_name: The name of the column from which to remove the index from.

options: (Optional) An associative array of options to control the index removal process. Key / Value pairs: name : values: user defined. The name of the index to remove. If not specified, a default name will be generated based on the table and column name. If during the index creation process (using the add_index method) and a name is specified then you will need to do the same here and specify the same name. Otherwise, the default name that is generated will likely not match with the actual name of the index.

Example A: Remove the (single-column) index from the users table on the email column.

    $this->remove_index("users", "email");

Example B: Remove the (multi-column) index from the users table on the email and ssn columns.

    $this->remove_index("users", array("email", "ssn") );

Example C: Remove the (single-column) named index from the users table on the email column.

    $this->remove_index("users", "email", array('name' => "index_on_email_column") );

Query Execution

Arbitrary query execution is available via a set of methods.

Execute method

The execute() method is intended for queries which do not return any data, e.g. INSERT, UPDATE or DELETE.

Example A: Update all rows give some criteria

    $this->execute("UPDATE foo SET name = 'bar' WHERE .... ");

Queries that return results

For queries that return results, e.g. SELECT queries, then use either select_one or select_all depending on what you are returning.

Both of these methods return an associative array with each element of the array being itself another associative array of the column names and their values.

select_one() is intended for queries where you are expecting a single result set, and select_all() is intended for all other cases (where you might not necessarily know how many rows you will be getting).

NOTE: Since these methods take raw SQL queries as input, they might not necessarily be portable across all RDBMS.

Example A (select_one): Get the sum of of a column

    $result = $this->select_one("SELECT SUM(total_price) AS total_price FROM orders");
    if($result) {
     echo "Your revenue is: " . $result['total_price'];
    }

**Example B (select_all): **: Get all rows and iterate over each one, performing some operation:

    $result = $this->select_all("SELECT email, first_name, last_name FROM users WHERE created_at >= SUBDATE( NOW(), INTERVAL 7 DAY)");

    if($result) {
      echo "New customers: (" . count($result) . ")\n";
      foreach($result as $row) {
        printf("(%s) %s %s\n", $row['email'], $row['first_name'], $row['last_name']);
      }
    }

Testing

The unit tests require phpunit to be installed: http://www.phpunit.de/manual/current/en/installation.html

Running the complete test suite

$ vi config/database.inc.php
$ mysql -uroot -p < tests/test.sql
$ psql -Upostgres -f tests/test.sql
$ phpunit

Will run all test classes in tests/unit.

Running a single test file

$ vi config/database.inc.php
$ mysql -uroot -p < tests/test.sql
$ phpunit tests/unit/MySQLAdapterTest.php

Some of the tests require a mysql_test or pg_test database configuration to be defined. If this is required and its not satisfied than the test will complain appropriately.

ruckusing-migrations's People

Contributors

albhaf avatar andre-lameirinhas avatar andrewfenn avatar barchard avatar bboure avatar blackfyre avatar capripot avatar davidwinter avatar franklincarson avatar garex avatar james-mckinnon avatar jaycode avatar jmayhak avatar kbadinelli avatar larsnystrom avatar markchalloner avatar neomilium avatar nuxwin avatar ricick avatar ruckus avatar salimane avatar sarahbackhouse avatar shiki avatar silverslice avatar sorenbronsted avatar stilliard avatar timtonk avatar tomasfejfar avatar victorb avatar voku avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ruckusing-migrations's Issues

multiple field unique indexes

I need to do something like this:

alter table tablename add unique index(columnname, id2);

but I can't seem to figure out how to do it without using an execute..

maybe something like this?

$this->add_index("customers", "columnname, id2", array("unique" => true));

Default .gitignore poses hazard for production environments

The .gitignore file in this project includes db/migrate/*.php as ignore directive. Since this package is not available as a packaged download anymore, this directive is likely to stay in production when downloading this repo. When using git as an SCM, this means any created migrations in the default configuration are silently not checked in, something that may easily go overlooked (well, it did here... D-:).

Rename main.php to ruckus.php

I think It's better to give main.php some identification. When deploying it with some other scripts, main.php doesn't tell immediately what this script is for. Renaming it to :

1 - ruckus with the shebang #!/usr/bin/env php at the top of the script
2 - ruckus.php

I think ruckus is the best but ruckus.php is also ok, at least it's better than main.php

What do you think ?

use a .sql file as a template [ feature request ]

It would be really nice if I could specify a .sql file as a starting point for deployment. for example If I want to move an existing site over to ruckusing I would like to be able to do a database dump and then do migrations off of that. is there a way to do this?

Undefined property error

I am getting the following error when I run:

php main.php db:setup

(class.Ruckusing_DB_Setup.php:26) Undefined property: Ruckusing_DB_Setup::$adapter

cannot create longblob field

I can't seem to figure out how to create a field of type 'longblob' without running a query after creating the table

Migration via an offset does not work

(more of a note to self).

I'm attempting to migrate DOWN via an offset (really I just want to rollback the last executed migration) via:

$ php ruckus.php db:migrate version=-1

But it does not succeed and only prints out:

Cannot migrate DOWN via offset "-1": not enough migrations exist to execute.
You asked for (1) but only available are (0): 

Consider using semantic version tags

With the rapid development going on in ruckusing-migrations at the moment it would be useful to start tagging releases as per http://semver.org/. This way the folks using Composer can more reliably lock themselves to a release instead of running on the dev-master branch, which often has backwards-incompatible changes.

Here are a couple more posts that go into a bit more detail about why proper version tagging is important for Composer packages:

In addition to this, a CHANGELOG.md document would be handy - especially if it documented how to upgrade between different tagged versions.

Deploy with Capistrano

So I'm easily able to go up with the migrations on Capistrano deploy.
I would like to implement going down on Capistrano rollback, how would you go about that?

Something like this, or is there any easier way?

On deploy, read from the db and save the belonging db version number in a file in the deployed directory.
Then on rollback, read from the file and take the db back to the right version.

Transaction Support

I would like the up and down methods to be wrapped in SQL transactions, if the backend supports it (and I believe they all do).

I was surprised to see that a table was left in my database after an execute statement errored out.

Why append the database to the modules path?

I don't understand why this is appending the database name to the migrations module path?

https://github.com/ruckus/ruckusing-migrations/blob/master/lib/Ruckusing/FrameworkRunner.php#L206

The migrations we use shouldn't be different per database. I want to write migrations for a module I'm using, and for those migrations to work across different databases.

Currently:

my_module/migrations/project_databasename/*.php
my_module/migrations/anotherproject_databasename/*.php

The migrations for these are identical, but currently duplicated.

Instead of:

my_module/migrations/*.php

Is this necessary? If not, can I propose we remove it? I'm happy to submit a PR.

Support for table prefixes (enhancement request)

Ruckusing should add support for table prefixes which can be configured in database.inc.php and will be applied automatically to every table name. This makes it easier to run migrations on hosts that force table prefixes or in cases where variable prefixes are necessary.

Running migrations on databases with a different names

I need to be able to run a set of migrations against databases with different names.

Eg I have 2 configurations dev and prod which have database names db_dev and db_prod

during development I generate a few migrations which end up in the folder ./migrations/db_dev

If I then run my alternative environment it will not run these because the database name is now db_prod. This occurs because of the function:

    public function migrations_directory()
    {
        return $this->_config['migrations_dir'] . DIRECTORY_SEPARATOR . $this->_config['db'][$this->_env]['database'];
    }

It would be a disappointing limitation if all of your databases had to have the same name in order for this to work.

Postgres Adaptor

Greetings,

I couldn't find anything in wiki on creating an adaptor for the Postgres DB. Any pointers on how I could go about doing this?

Thanks,
Stan

InnoDB table associations.

I am trying to create a database where indexes are associated and deletes/updates cascade, The only way I can figure out how to do this is to use a query:
$this->execute('
ALTER TABLE events
ADD FOREIGN KEY ( restaurant_id )
REFERENCES restaurants (id)
ON DELETE CASCADE
ON UPDATE CASCADE
');

It would be nice if there was a cleaner way of doing this.

Feature Request: SQLite support

Would let users use Ruckusing to setup temporary databases in SQLite ( really helpful when doing DB testing in PHPUnit, for example )

Coding standards

is there any coding standard that you prefer to use? I'm currently integrating ruckusing in our workflow but find there are some features missing that i would like to implement. Then i took a look at the code and saw a mixture of tab- and space indentation, etc ...

I would like to settle on one thing before i start filing pull requests with my updates. Tabs or spaces for indentation. I'm for spaces following the Zend Framework coding standard.

Shared Development Model

Is their a recommended approach/best practice for shared development using this framework? I am not familiar with Ruby and the original DB migrations framework.

If there are multiple developers in a project. Which parts of the ruckusing framework are shared in CVS or subversion? Let's assume one developer adds new functionality to an application and creates a migration using "php generate.php ...". Would the developer then commit these migrations to the CVS/SVN repository to be picked up by other developers?
This is the direction I'm headed in but wanted get some feedback.

Thanks,
Stan

Simple down migration

Now you need to use
php main.php db:migrate VERSION=20110716134657
I'd suggest having also the option to use
php main.php db:migrate DOWN=N
that would migrate N revisions DOWN. The problem with current solution is that you need to get the propper timestamp from the schema_migrations table to insert into the CLI, which is really annoying when not connected to the DB.

It can be implemented fairly easily - you can do sth like:
SELECT version FROM schema_migrations ORDER BY version DESC LIMIT N,1
that will select N-th oldest version. That would simplify thing a lot. Unfortunately it won't work this way for UP migrations as they are not in the table (but could be done using ordered filesystem iteration). But usually you don't need to migrate "some" revisions up, but mainly to the last revision. But migrating down the last revision has a strong use case in correcting mistakes ;)

As with my other issues I'll try to fix it myself later (when I finish the project I'm using RU for = september)... if you would not fix that first :)

Merging generate and main into one file

I'm not sure what was the motivation of using multiple files - the migration file generation can as well be turned into a task, couldn't it? Why it's in it's own file (mirroring the bootstrap code).

Exception handlers set no exit code

Exception handlers set no exit code, which causes problems when migrations are called from bash scripts.

Fix:

Index: ruckusing-migrations/lib/Ruckusing/Exception.php
===================================================================
--- ruckusing-migrations/lib/Ruckusing/Exception.php    (revision 6344)
+++ ruckusing-migrations/lib/Ruckusing/Exception.php    (working copy)
@@ -79,6 +79,7 @@
     public static function errorHandler($code, $message, $file, $line)
     {
         file_put_contents('php://stderr', "\n" . basename($file) . "({$line}) : {$message}\n\n");
+        die(1);
     }

     /**
@@ -89,6 +90,7 @@
     public static function exceptionHandler($exception)
     {
         file_put_contents('php://stderr', "\n" . basename($exception->getFile()) . "({$exception->getLine()}) : {$exception->getMessage()}\n\n");
+        die(1);
     }

 }

Merging/Branching Brainstorm (db:migrate apply function?)

I'd like to get anyone's general ideas about the feasibility of having merging capabliities built in. For example:

Dev Branch:
Adds migration 1 and 2; commits.

Topic Branch:
Checkout dev branch, up to date with 1 and 2.
Adds migration file 3, does not yet merge back to dev.

Dev Branch:
Adds migration file 4. Commits.

Topic Branch:
Finished work, merges to dev branch.

Develoer in dev branch now has 1, 2, 3, and 4, but since 4 has already been run prior to getting migration file 3, file 3 never runs.

Ideally, it might be nice to be able to see a diff of all migrations that have not run yet, since they will be sprinkled in various places of your migrations folder, and run them either all once or specifically (ex: db::migrate apply=12121220000)

Generate all SQL migration queries

I think very good feature will be possibility to generate all migration queries and save for example in file, for example:

php rucus.php db:get_queries > file.sql

Why? I my case I develop some application at linux, but in hosting server I dont have shell and I must run all queries from phpMyAdmin, so when I have file with queries everything will be easier.

Invalid error handler

ErrorHandler (Ruckusing_Exception.php:79) cannot call exit(1) for warnings.

E.g. when pg_query fails not only it sets error code but also it generates a warning.
Currently errorHandler calls exit(1) on warnings and db errors are not handled properly (e.g. migration that failed is not shown).

Multiple Databases

How would you recommend working with multiple databases?

I know the create_database() function will allow you to create a new database but not return an object to add tables to or such. I don't think any of the functions to alter or insert tables allow an argument to be passed that sets the database to perform the action.

Is this a future plan or does this go against the primary goal? Is there a recommended way to configure ruckusing-migrations to easily allow for multiple dbs?

Composer support

Hello ;

I want use that framework to manage database migrations on my project. I would recommend to add composer support for easy integration. It's possible ?

PHP Storm autocomlete

I think having a working autocompletion for the methods provided by ruckusing-migrations. This partially works until the a create_table method call on the $insertYouVarNameHere variable.
clipboard02

Wrong db adapters path construction

Ruckus treats all dirs under "Adapter" as db adapters.
It doesn't work for svn 1.6, which adds .svn folders.

Error log:
FrameworkRunner.php(454) : require_once(ruckusing-migrations/lib/Ruckusing/Adapter/.svn/Base.php): failed to open stream: No such file or directory

error on second migration script with the same class name

with two files to be migrated like (generated with generate.php):

20101001002834_UpdateTableTransport.php
20101209002840_UpdateTableTransport.php

both generated with:

generate.php update_table_transport

migration fails on second file with

PHP Fatal error: Cannot redeclare class UpdateTableTransport

not big show stopper though, as it is still possible to continue by running migration process second time

cool tool btw!

Us of different migrations dirs

Is there a possibility to add multiple directory's to read the migrations?
I want this to set the migrations in the module (a git submodule)
but run the migrations from the base project.

limits are ignored

The limit option is ignored in the latest master version (6ab9673):

$t = $this->create_table('test');
$t->column('nolimit', 'string');
$t->column('limit', 'string', array('limit' => 50));
$t->finish();

Result:

CREATE TABLE `test` (
  `nolimit` varchar(255) DEFAULT NULL,
  `limit` varchar(255) DEFAULT NULL,
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Support for working in different branches in parallel

Currently I'm in a situation where I've forked our master (git) and have been working on a new feature for a month. So far I have 44 changes to the database (ruckusing migrations), but in the same period of time master have "moved" ahead with about 20 of its own changes to the database.

So far I've rebased my fork on top of master and until now gotten all database changes in my development environment because of that. But when my feature is ready to go into production and I merge back into master there is no guarantee my migrations files will be applied in production.

Migration files - new feature (NF)
1 NF
2 NF
5 NF

Migration files - master
3 master
4 master - currently deployed in production

Migration files - master merged with NF
1 NF
2 NF
3 master
4 master - currently deployed in production
5 NF

In the above example when we update our production system migrations files 1 and 2 won't be applied because 3 and 4 is already applied. Do you have a recommendation for this scenario, if not I would like to request support for this (working in parallel on different branches which is merged back together).

Right now the only solution I can come up with is to rename all my 44 migration files to something that is newer than the current deployed version in production.

FULL TEXT searching

Is Ruckusing able to generate a full text search index like below?

ALTER TABLE test ADD FULLTEXT(title, article);

Migrations execute function should allow semicolons

Currently the execute function splits the query string given by semi colons, see: https://github.com/ruckus/ruckusing-migrations/blob/master/lib/Ruckusing/Adapter/MySQL/Base.php#L325

But that doesn't take into consideration semicolons inside of quotes that should not be treated this way.
E.g.

insert into a(id,name) values(1,'test'); insert into b(id,name) values(1,'another test');

That should work this way, however:

insert into a(id,name) values(1,'test;test')

should not be split!
This should apply to semicolons inside single and double quotes.

Util/Naming.php -> class_from_file_name

this function not working like it should under windows server.
little fix done by me:

$file_name = str_replace('\\', '/', $file_name);
//we could be given either a string or an absolute path
//deal with it appropriately
$parts = explode('/', $file_name);

No progress indication if a migration is slow

ruckus.php does not currently print any output until all migrations have finished.

If one or more migrations take a very long time, then this can be disconcerting. It is not clear whether ruckus.php has started or not.

It would be better if a "starting migration x" message were printed before each migration started.

(Tested on version d8b1e737 (current master) on Windows with PHP 5.4.13 + Cygwin shell)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.