All available documentation can be found here.
doctrine / migrations Goto Github PK
View Code? Open in Web Editor NEWDoctrine Database Migrations Library
Home Page: https://www.doctrine-project.org/projects/migrations.html
License: MIT License
Doctrine Database Migrations Library
Home Page: https://www.doctrine-project.org/projects/migrations.html
License: MIT License
All available documentation can be found here.
In AbstractCommand::getMigrationConfiguration() the helperset is checked first for the db helper.
It would be more useful if the --db-configuration option is checked first to allow overrides in the working directory with a cli-config.php file.
Hi,
I odn't know if the problem is in doctrine migration or the dbal but anytime I do a migration diff, the last 2 lines are to drop and recreate those foreign keys (in the up and down methods).
Any idea of the source of the problem ?
$this->addSql("ALTER TABLE ordersdomains DROP FOREIGN KEY FK_D4D861CF8D9F6D38");
$this->addSql("ALTER TABLE ordersdomains ADD CONSTRAINT FK_D4D861CF8D9F6D38 FOREIGN KEY (order_id) REFERENCES `order` (id) ON DELETE CASCADE");
With the feature $schema->renameTable('old', 'new');
you end up losing your data due to how this function works.
Doctrine creates a new table with the old table definitions and then drops the old table. It fails to migrate the data into the new table. There are two solutions to this problem (1st one preferred):
RENAME TABLE old TO new
) DocumentationThoughts appreciated.
In Version the connection is committed even during a dry run.
This isn't an issue for SQL added via addSQL
(or through SchemaManager
), which are never executed, however, a reference to the connection is protected
in AbstractMigration
, so it's possible to use the connection to do advanced data manipulation: using a PHP function to modify data, for example. These changes are committed even during a dry run.
It seems that either the $connection
in AbstractMigration
should be private
(a BC break) or the connection should be rolled back.
We use the protected
connection once in a while to do complex data manipulation. One could argue that this migration tool should only be used for static SQL, but so far we've found it easiest to pool all DDL, DML and custom transformations in one place.
Hello, I need to execute some inserts/deletions/updates on entities in the database during migrations. I tried to use the connection field of the migration, like below:
public function up(Schema $schema)
{
$this->_connection->insert('user', array(
'login' => 'admin',
'name' => 'Admin',
'password' => crypt('admin'),
'status' => 1,
));
}
But when executing migrations, it prints the error message "No SQL commands found", unless I add this line:
$this->_version->markMigrated();
So, how am I supposed to perform INSERTS/DELETIONS/UPDATES on data during migration of the database?
Thanks for your help.
I'm getting different results from doctrine ORM and doctrine migrations for creating auto incrementing id columns in oracle.
Migrations is missing the column name in the pattern {dbname}_{column}_seq. It looks like there are two different strategies for generating sequence names between ORM and DBAL/Platform/OraclePlatform.
Creating my entity in PHP annotations like:
/**
* @Entity
* @Table(name="types")
* */
class Type
{
/**
* @Id
* @Column(type="bigint")
* @GeneratedValue(strategy="AUTO")
*/
private $id;
}
and running schema-tool:update --dump-sql results in:
CREATE SEQUENCE types_id_seq START WITH 1 MINVALUE 1 INCREMENT BY 1
doing this in doctrine migrations:
public function up(\Doctrine\DBAL\Schema\Schema $schema)
{
$table = $schema->createTable('types');
$table->addColumn('id', 'bigint', array('autoincrement' => true));
$table->setPrimaryKey(array('id'), 'primary');
}
results in:
CREATE SEQUENCE TYPES_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1
In Doctrine\DBAL\Migrations\Configuration\Configuration::createMigrationTable()
the version column is specificed as string.
However, the version format is YYYYMMDDHHMMSS and when getCurrentVersion()
queries the table it does not convert the values to strings:
$sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";
Therefore, you are relying on the database to implicitly convert the supplied integers to string. Postgresql in particular doesn't do this, so you get:
ERROR: operator does not exist: character varying = bigint
LINE 1: ...c_owner.doctrine_migration_versions WHERE version IN (201204...
Therefore, I think we need to create the table such that the version column has format integer or bigint, or change getCurrentVersion()
so that it quotes the values in the implode function.
I'm happy to prepare a PR if there is a consensus on which approach is preferred.
In Configuration::getCurrentVersion()
https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php#L363
used 'LIMIT 1' in SQL clause. This construction is not supported by SqlSrv.
I've cloned this repository, then downloaded all the dependencies using update
composer command and after I run phpunit
this is what I get:
$ phpunit
PHPUnit 3.6.12 by Sebastian Bergmann.
Configuration read from /var/www/doctrine-migrations/phpunit.xml.dist
....PHP Fatal error: Class 'Symfony\Component\Yaml\Yaml' not found in /var/www/doctrine-migrations/lib/Doctrine/DBAL/Migrations/Configuration/YamlConfiguration.php on line 39
PHP Stack trace:
PHP 1. {main}() /usr/bin/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46
PHP 3. PHPUnit_TextUI_Command->run() /usr/share/php/PHPUnit/TextUI/Command.php:130
PHP 4. PHPUnit_TextUI_TestRunner->doRun() /usr/share/php/PHPUnit/TextUI/Command.php:192
PHP 5. PHPUnit_Framework_TestSuite->run() /usr/share/php/PHPUnit/TextUI/TestRunner.php:325
PHP 6. PHPUnit_Framework_TestSuite->run() /usr/share/php/PHPUnit/Framework/TestSuite.php:705
PHP 7. PHPUnit_Framework_TestSuite->runTest() /usr/share/php/PHPUnit/Framework/TestSuite.php:745
PHP 8. PHPUnit_Framework_TestCase->run() /usr/share/php/PHPUnit/Framework/TestSuite.php:772
PHP 9. PHPUnit_Framework_TestResult->run() /usr/share/php/PHPUnit/Framework/TestCase.php:751
PHP 10. PHPUnit_Framework_TestCase->runBare() /usr/share/php/PHPUnit/Framework/TestResult.php:649
PHP 11. PHPUnit_Framework_TestCase->runTest() /usr/share/php/PHPUnit/Framework/TestCase.php:804
PHP 12. ReflectionMethod->invokeArgs() /usr/share/php/PHPUnit/Framework/TestCase.php:942
PHP 13. Doctrine\DBAL\Migrations\Tests\Configuration\AbstractConfigurationTest->testMigrationDirectory() /usr/share/php/PHPUnit/Framework/TestCase.php:942
PHP 14. Doctrine\DBAL\Migrations\Tests\Configuration\YamlConfigurationTest->loadConfiguration() /var/www/doctrine-migrations/tests/Doctrine/DBAL/Migrations/Tests/Configuration/AbstractConfigurationTest.php:14
PHP 15. Doctrine\DBAL\Migrations\Configuration\AbstractFileConfiguration->load() /var/www/doctrine-migrations/tests/Doctrine/DBAL/Migrations/Tests/Configuration/YamlConfigurationTest.php:12
PHP 16. Doctrine\DBAL\Migrations\Configuration\YamlConfiguration->doLoad() /var/www/doctrine-migrations/lib/Doctrine/DBAL/Migrations/Configuration/AbstractFileConfiguration.php:65
Documentation link in readme leads to http://www.doctrine-project.org/projects/migrations/2.0/docs/en
But it's 404 page. Not sure where is actual documentation?
Edit: Link in description is broken as well: http://www.doctrine-project.org/extension/migrations
I created two simple entities https://github.com/stfalcon/BlogBundle/tree/master/Entity
And generated migrations diff https://github.com/stfalcon/portfolio/blob/master/app/DoctrineMigrations/Version20110520075206.php
Command doctrine:migrations:migrate works fine. But I get error when try downgrade last migration:
Migrating down to 20110520062748 from 20110520075206 -- reverting 20110520075206 -> ALTER TABLE blog_posts_tags DROP FOREIGN KEY Migration 20110520075206 failed during Execution. Error SQLSTATE[HY000]: General error: 1005 Can't create table 'stfalcon_com_development.#sql-5af_119' (errno: 150) [PDOException] SQLSTATE[HY000]: General error: 1005 Can't create table 'stfalcon_com_development.#sql-5af_119' (errno: 150)
As Symfony 2.3 SE has minimum stability set to stable this package isn't working. Why not create a stable release?
http://symfony.com/blog/upgrading-your-symfony-projects-the-easy-way
In generated migrations classes I have to put an space in all:
REFERENCES name(id)
like that:
REFERENCES name (id)
to avoid sql errors when executing
Using mysql Ver 14.12 Distrib 5.0.77
see #94 (comment)
Hi,
I'm using doctrine migrations along with Symfony 2 and DoctrineMigrationsBundle on a PostgreSQL database. Discovered a strange behaviour of the doctrine:migrations:migrate command when trying to migrate down.
I added a foreign key with this SQL on up():
ALTER TABLE show_instance ADD CONSTRAINT FK_7B5450313F82F4D7 FOREIGN KEY (redbtnCampaign_id) REFERENCES redbtn_campaigns(campaign_id) ON DELETE SET NULL NOT DEFERRABLE INITIALLY IMMEDIATE
On down() the following SQL is used:
ALTER TABLE show_instance DROP CONSTRAINT FK_7B5450313F82F4D7
doctrine:migrations:migrate VERSION
(down) fails to drop the foreign key and tells me that:
[PDOException]
SQLSTATE[42704]: Undefined object: 7 ERROR: constraint "fk_7b5450313f82f4d7" of
relation "show_instance" does not exist
Although when I look it up in the database, it is there! And executing the exactly same drop command directly on the database works.
I'm using the latest version of doctrine/migrations and the latest version of the symfony/DoctrineMigrationsBundle (on branch 2.0)
Maybe you can help me?
Thanks,
Edi
http://github.com/doctrine/migrations/blob/master/phar-cli-stub.php#L23
The downloadable PHAR (http://github.com/doctrine/migrations/downloads) fails the ClassLoader require_once
as it doesn't reference phar://
.
Current, doctrine/migrations uses tasks
\DoctrineExtensions\Migrations\Tools\Cli\Tasks\MigrateTask
The latest version of doctrine/doctrine2 uses "commands" and has switched from using Cli to a HelperSet:
\Doctrine\DBAL\Tools\Console\Command\RunSqlCommand
Is this library (or will this library be) the standard migrations tool for Doctrine2, or are migrations should we just monitor doctrine/doctrine2 for that functionality?
The Symfony manual encourages users to go and fetch the ORM Entity Manager inside postUp functions to go and set up entities/manipulate data (see http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html#container-aware-migrations).
The problem with this is that it doesn't get along with dry-run operations. The console ends up with an error, as the postUp function actually executes, and the entity manager is oblivious to the fact that it's only pretending to be doing operations.
As far as I could tell, there isn't an exposed way to detect dry runs and therefore skip processing inside your postUp functions.
Either the Doctrine EM needs to be able to detect dry runs and just log what it wanted to do, or we need a way of detecting dry run mode and choosing to skip.
Hello,
Config : symfony 2.2, os x 10.8.3, PHP 5.4.4, Apache 2, Database ; oracle OSI 8.
When I type the doctrine:migrations:diff, I always have this line generated :
public function up(Schema $schema)
{
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "oracle");
$this->addSql("DROP TABLE MIGRATION_VERSIONS");
}
So the big problem is : always when I create a DIFF migration file, he drop the table migration and re-create it after with the new migration value. When I get my third migration file he forgot that he already have execute the first one (who have been drop by the second one) and generate a lot of error.
So why he always generate this drop table ?!
Thanks to help me !
I'm not really sure is it a bug or just my misunderstanding, but when I'm using diff command like:
doctrine:migrations:diff --filter-expression='~^(?!t_)~'
I expected to see all tables not prefixed with "t_" in generated migration. But prefixed tables are in it. This is because "filter-expression" option is applied only for $fromSchema and ignored for $toSchema, which is generated from entities metadata.
A bit confusing, as for me. :)
May be it'll be better to apply filter for all schemas?
For example like this:
$tool = new SchemaTool($em);
$fromSchema = $conn->getSchemaManager()->createSchema();
$toSchema = $tool->getSchemaFromMetadata($metadata);
if ($filterExpr) {
$tableNames = $toSchema->getTableNames();
foreach($tableNames as $tableName){
$tableName = substr( $tableName, strpos($tableName,'.') + 1);
if( !preg_match( $filterExpr, $tableName ) ){
$toSchema->dropTable($tableName);
}
}
}
When you deploy an existing application which has migrations to a new test server, for example, then its database has the current schema definition and does not have to get the existing migrations applied. For this, you need to run the command
./doctrine migrations:version YYYYMMDDHHMMSS --add
for all existing migrations to tell the application that they do not have to be applied, if I understood things correctly. A small command extension like
./doctrine migrations:version --all --add
would be extremely helpful in this case. Would this seem possible? An alternative would be to integrate the migrations with the schema:create command, but that might be more difficult and maybe not even desirable.
Thanks so much for considering.
Regards, mg
This is the correct project page: http://www.doctrine-project.org/projects/migrations.html (corrected)
Old URL: http://www.doctrine-project.org/extension/migrations
After creating the version table at the database, if we issue a migrations:status and the database server is SQL Server, it's appending the LIMIT 1 to the query.
Probably it might be a problem with the DBAL Plataform for SQL Server (pdo_sqlsrv), but I saw at migrations / lib / Doctrine / DBAL / Migrations / Configuration / Configuration.php line 431 that it get this info from the plataform.
I've encountered a strange behavior while using Migrations with ORM on PostgreSQL. When the diff command generates migration, it adds drops for indexes to down part even if the index is dropped automatically by some of previous queries.
According to PostgreSQL documentation for DROP COLUMN
:
Indexes and table constraints involving the column will be automatically dropped as well. You will need to say CASCADE if anything outside the table depends on the column, for example, foreign key references or views.
So when there was a field foo with an index on it, the migration first drops the column and after that, it tries drop the index (which doesn't exist anymore at that time).
The solution (and a workaround) seems to be either to swap these two SQLs so the index is dropped first or to completely skip generating SQLs for dropping indexes which are on some of the columns dropped previously.
I created a test case & two solutions here:
http://github.com/ericclemmons/migrations/commits/hotfix%2Fhtml-in-sql-query-output-bug
I believe the bug fix may be better suited in \Symfony\Component\Console\Output\Output
. Either that, or have Version.php
or the OutputWriter
specifically use the Output::OUTPUT_PLAIN
or Output::OUTPUT_RAW
constant.
the problem arises when multiple developers work with migrations and in one case migrations could be skipped:
The 20120228114838 is skipped because last migration in DB is newer then the one received, and since a full cross-ref with DB is not run, the migration does not get executed.
I noticed that having three entities A, B, C configured as it follows:
make the "doctrine:migrations:diff" command create only the 2nd relationship, this happens also if you switch the order of them. To obtain the desired two relationship I had to write one first, doctrine:migrations:diff, and then add the other one and do again doctrine:migrations:diff
Here's my symfony2's deps file: http://pastebin.com/kLZ9cXd1
Do you confirm it?
other doctrine projects do not have the github issue tracker but use doctrine jira. this project has both the github issue tracker as well as issues in jira at http://www.doctrine-project.org/jira/browse/DMIG
Hello, I need to execute some inserts/deletions/updates on entities in the database during migrations. I tried to use the connection field of the migration, like below:
public function up(Schema $schema)
{
$this->_connection->insert('user', array(
'login' => 'admin',
'name' => 'Admin',
'password' => crypt('admin'),
'status' => 1,
));
}
But when executing migrations, it prints the error message "No SQL commands found", unless I add this line:
$this->_version->markMigrated();
So, how am I supposed to perform INSERTS/DELETIONS/UPDATES on data during migration of the database?
Thanks for your help.
I declared my entity with the indexes section, like this:
indexes:
IDX_ADDRESS_CITY:
columns: city_id
but, the Diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");
and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");
Hi,
i think there's an error in the Doctrine\DBAL\Migrations\Tools\Console\Command\DiffCommand.php on line 89 -> $version = date('YmdHms');
i think this line should be replaced with $version = date('YmdHis'); to get the version files in the correct order
When a field has a default value defined by options={"default" = 0}
, migrations:diff
always marks the field as changed, thus generating a migration with unneeded statements.
How to reproduce
Create an entity as follows:
/**
* @ORM\Table(name="dummy")
* @ORM\Entity
*/
class DummyIdentity
{
/**
* @ORM\Column(type="integer")
* @ORM\Id
*/
private $id;
/**
* @ORM\Column(type="integer", options={"default" = 0})
*/
private $dummy;
}
doctrine:migrations:diff
doctrine:migrations:migrate
doctrine:migrations:diff
againThe migration generated by 3. will have a statement to change the dummy
field, even though it wasn't changed:
ALTER TABLE dummy CHANGE dummy dummy INT DEFAULT 0 NOT NULL"
Using the following command
./doctrine migrations:diff
does always create a version file even if there are no changes to be made to the current schema.
The content of this file is for example
namespace Application\Migrations;
use Doctrine\DBAL\Migrations\AbstractMigration,
Doctrine\DBAL\Schema\Schema;
/**
* Auto-generated Migration: Please modify to your need!
*/
class Version20121210110653 extends AbstractMigration
{
public function up(Schema $schema)
{
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
}
public function down(Schema $schema)
{
// this down() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
}
}
In Doctrine\DBAL\Migrations\Tools\Console\Command\DiffCommand there is always the 'abortIf()' line added to the Version-Code.
As we want to use Migrations in a semi automatic build process these 'empty' versions are really annoying.
(Kind of duplicates #41)
it is expected to be here as it could be used in doctrine migration.
Other parts already implemented: in Doctrine\ORM\Tools\ShemaTool::_gatherColumn it is fetch from metadata and in Doctrine\DBAL\Schema\Comparator::diffColumn it is already checking if it is the same
Issue moved from: doctrine/DoctrineMigrationsBundle#35
Fails when there is not yet migrated versions: "IN ()" throws mysql error
public function getCurrentVersion()
{
...
/* BEFORE
$sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";
*/
/* AFTER */
if (count($migratedVersions) > 0 ) {
$sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";
} else {
$sql = "SELECT version FROM " . $this->migrationsTableName . " ORDER BY version DESC";
}
...
}
Doctrine builds wrong schema for foreign keys in mysql migrations.
My entities:
/**
/**
doctrine migrations:migrate in current doctrine version:
up:
ALTER TABLE Catalog_Field ADD CONSTRAINT FOREIGN KEY (groupId) REFERENCES Catalog_FieldGroup(id)
down:
ALTER TABLE Catalog_Field DROP FOREIGN KEY
should be:
up:
ALTER TABLE Catalog_Field ADD CONSTRAINT Catalog_Field_ibfk_2
FOREIGN KEY (groupId) REFERENCES Catalog_FieldGroup(id)
down:
ALTER TABLE Catalog_Field DROP FOREIGN KEY catalog_field_ibfk_2
Hi,
I am not sure if this feature is already implemented. I couldn't find it. I am setting up doctrine migrations on top of silex and I have to pass --configuration argument everytime I run it at commandline or I have to change working dir to the same as migration configuration file.
php console.php migrations:status --configuration=config/migrations.yml
or
chdir(DIR.'/config');
It would be nice to allow configure it before running commandline.
Execute the command migrations diff in the case where is no changes creates a new file
./app/console doctrine:migrations:diff
Generated new migration class to "/home/songoq/project/app/DoctrineMigrations/Version20110803142018.php" from schema differences.
cat /home/songoq/project/app/DoctrineMigrations/Version20110803142018.php
...
...
...
class Version20110803142018 extends AbstractMigration
{
public function up(Schema $schema)
{
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
}
public function down(Schema $schema)
{
// this down() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");
}
}
In Doctrine2 one of the params for the db config is 'username', but in Migrations it is 'user'. Could this be made consistent?
Hi, guys. I'm trying to perform some migrations to alter my database schema and then normalize data on the new tables.
For example: I want to create new entities based on those that already exist in my database. So, raw SQL is not an option here. Then I'm trying to use the entity manager from container to retrieve entities and create new ones from them.
I got stuck when I need to persist an entity and then gets it to use in another entity relation. The id from the first flushed entity is null. Can it be because the whole migration is executed inside a database transaction?
If it is really occurring by the database transaction, is it possible to make it more flexible in the way we can perform this kind of migration?
I'm not sure if here is the right place for this kind of post... but it could be an improvement for migrations.
Thanks.
Currently it is only possible to have a single folder with the migrations in it, usually in app/DoctrineMigrations
. I don't know complicated this may be, or which pitfalls can appear, but I think it would be interesting, if it is possible to have different migrations per bundle. I thougt of something similar to DoctrineFixturesBundle
, but for migrations.
Hello.
On cakephp, there was a great function that allow us to simply migrate from a version n to version n-1.
Migrate down.
Do you think you could implement such a function ?
The nicea thing is taht when you actually test your migration, you can easily go back to the last version without wondering what name it has.
When you have to generate / modify / update few time the migration script to get the right result, it's much easier to test that the new script works fine in both way like that.
Best regards,
Pierre
Please consider creating a tag for a stable release version.
This project's Github page (https://github.com/doctrine/migrations) links to the http://www.doctrine-project.org/extension/migrations page which doesn't exist anymore.
Change it to http://www.doctrine-project.org/projects/migrations.html .
Easy but nice :)
Would it be possible to add these before and after diff commands:
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
because when we change primary keys, executing version will return a mysql error on foreign keys integrity.
I am using Symfonx 2.0.17 and I try to execute php app/console doctrine:migrations:diff
The problem is that this is not working from the last commit : 5dffedd
It should be possible to request an older version and the best idea would be to add a tag for the version which is compatible with Doctrine 2.1
PHP Fatal error: Uncaught exception 'PharException' with message 'illegal stub for phar "/var/www/nolimits/public/modules/migrations/vendor/migrations/build/doctrine-migrations.phar"' in /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php:38 Stack trace: #0 /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php(38): Phar->setStub('setStub() /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php:38
Running from the latest commit aab5b20 and using PHP 5.3.5
When reverting to "" (empty string) , The system is supposed to revert every migations which works fine if there are any migration done previously but if there are none, PHP issues a warning :
Warning: array_combine(): Both parameters should have at least 1 element in F:\workspace_php\claronext\vendor\doctrine-migrations\lib\Doctrine\DBAL\Migrations\Configuration\Configuration.php line 470
The line can be found here :
It is a strange behaviour of PHP (and undocumented : http://php.net/manual/en/function.array-combine.php ) but as long as it is not fixed in the language, an extra test should do the trick.
PS : I'm using php 5.3.5with zend engine 2.3.0 and xdebug 2.1.0 on windows
In one of my migration scripts I needed to rename the column and tried to use the renameColumn() method.
Unfortunately, this did not worked - it only dropped it.
Looking at the code of the method, there's definitely something missing:
/**
* Rename Column
*
* @param string $oldColumnName
* @param string $newColumnName
* @return Table
*/
public function renameColumn($oldColumnName, $newColumnName)
{
$column = $this->getColumn($oldColumnName);
$this->dropColumn($oldColumnName);
$column->_setName($newColumnName);
return $this;
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.