On the Etsy "Code as Craft" blog there's a recent post about their move to using the GeoNames service internally rather than the external, third-party API previously in use.

People are passionate about where they live. At Etsy we need to keep track of lots of different locations, such as buyers' billing and shipping addresses and sellers' shop locations. As Etsy continues to expand internationally we wanted to provide better localization and translations for our location place names. We determined that the best way to effect this change was to move from using a closed location API provider to internal services backed by the open GeoNames data set.

The post details some of the steps in the process including the mapping of the current data to the new structure (the script is available on github). They talk about how they mapped their old data over (trial and error sometimes) and the creation of a database of "GeoNameIDs" for each customer in their records. They've also implemented a Lucene/Solr search for improved searching and auto-suggestion based on the user's location.

The Zend Framework project has announced a major move for the framework's development - the Zend Framework v1 repositories will be moving from Subversion to Git over the next year or so.

Since its inception, Zend Framework 1 has used Subversion for versioning. However, as we approach its end-of-life (which will occur 12-18 months from the time this post is written), and as our experience with ZF2 processes becomes more familiar, we -- the Zend team and the Community Review team -- feel that we can better support ZF1 via GitHub. As such, we will be migrating the ZF1 Subversion repository to GitHub this week. Please read on for details!

The post details the steps that'll be taken during the process including the changing of the location of the "master" branch (and how to change svn to point to it) and the updates to the integration of the Dojo libraries. They also talk some about the "extras" repository and how things will work with the Issue Tracker and pull requests in the future.

The repository and issues migration is the first step in a series of planned migrations. We also plan to eventually migrate our wiki to GitHub; this will allow us to offload functionality from the main ZF website, and also consolidate all development-related functionality (other than the mailing list) in a central location.

If you're a PHPFog user, you know that they're discontinuing the service in favor of their AppFog product. If you're looking to migrate over to this from PHPFog, you should check out this new article from PHPMaster.com with some of the differences between the two services.

Have you heard PHPFog is coming to an end? No, well - it is. That's right, in a recent announcement on their mailing list, the company has said that PHPFog will be no more by the end of January, 2013. But if you're on their platform, don't panic! The new, combined platform may be even better than what you're accustomed to with them now.

He talks about some of the things that are different including the technologies it employs, addons it provides, the differing deployment process and when teh final cut-off date is. He links to their own migration guide for most of the steps but mentions one specific change that might trip you up - the change to store connection information in the "VCAP_SERVICES" environment variable.

Rob Morgan has a recent post showing you how to use Phinx, a PHP-based database migration tool, to handle your database changes (both "up" and "down").

Earlier this year I decided to open-source one of my personal software projects - Phinx. Phinx is a database migration tool (think Ruby on Rails ActiveRecord migrations) where can you describe all of your database transformations in pure PHP. I have used this tool for many of my consulting projects, however it still took a lot of effort to turn it into a re-usable product. In this tutorial I'm going to explain how to install Phinx and use it with a simple guestbook application.

He uses a sample guestbook project for his example, showing how to get it all installed and how to create a migration that adds a "posts" table.

PHPMaster.com has continued their series about the Laravel framework today with this new tutorial they show you how to use the command line tool Artisan to work with database migrations.

For those who struggle with maintaining their database schema, or who have problems applying updates and often revert them, there is a solution. Laravel, the MVC framework which I wrote about previously, offers you migrations.

On the surface, the migrations are simple sets of "up" and "down" methods that allow you to apply and remove the changes required for the migration. It also allows you to perform a "rollback" on the updates just made and a "reset" to clear out all changes and start over from the base. There's also a shortcut to help generate migration code from a configuration string.

In this latest post to his site Stefan Koopmanschap shares a solution he's found to migrating data with Doctrine2 from an existing structure.

A project that I'm working on right now required me to migrate data from the existing database to the new database and database structure. Since the application is built on top of Symfony2, I decided to write a Command that would take care of the migration. I ran into an issue though: Doctrine2 insisted on creating new IDs where I wanted to keep the old one. The solution turned out to be really simple.

The actual code for the Command is only a few lines long - it just turns off the "AUTO" strategy for each of your entities, making it ignore any IDs you have set on the entity already.

On the LeaseWeb Labs blog there's a continuation from a previous post about migrating your Symfony1 application over to Symfony2. In the first part of this series of posts, Stefan Koopmanschap talked about wrapping your code to make it work. In this second post, Maurtis van der Schee tackles two issues Stefan mentioned - performance problems and handling authorization/authentication.

On December 21, 2011 Stefan Koopmanschap wrote an excellent article on this blog titled "Painless (well, less painful) migration to Symfony2." [...] We were very much inspired by his passionate elucidation and we were fully convinced of the urge to start migrating to Symfony2 as soon as possible. However, he also provided us with a "A word of caution" about 2 things: performance and authentication/authorization. This might get some people worried, but not us: it challenged us to find a solution for those two open issues.

They explain why these two things are a problem and some of their solutions they've created - a .htaccess for routing and manually replicating the Symfony2 session in the Symfony1 code. Included in the post are the rewrite rules and code to make these two things happen (and a small configuration change to make them work).

In a new post to his blog Dave Marshall shares a homegrown migration tool he's created to help make database migrations a simpler task - phpmig.

I've previously blogged about migrations with phing and dbdeploy and also porting ActiveRecord::Migrations to PHP, now here I am again blogging about yet another way of doing migrations in PHP projects. Only maybe this time it's different, maybe this time I've found a way I'm happy with...? Phpmig is a simple migrations system that was written to be easily adopted regardless of the framework or libraries you are using. It requires a little bit of setting up, but if you know you should be using migrations, you're probably more than capable.

He's worked up a sample application to show you how to get things set up and working - a basic Silex-based application. Phpmig is used to create a basic bootstrap for the deployment that includes the use of Pimple for dependency injection and a command-line interface to generate a migration skeleton class for the up/down methods. The source for phpmig can be found on github.

Chris Hartjes, after finally figuring out an issue with database migrations with Doctrine on a Zend Framework application, has posted about the process to his blog today. As he notes:

This posting is a lesson on the value of actually looking at the source code of a third-party library when you are trying to figure something out...

His problem wasn't with the features of Doctrine and how easy it made to automate things in his environments (continuous integration). His issue was that Doctrine wanted to run all of the migrations every time it was executed. Upon closer inspection, he found the key - a migration_version table in his database that held current migration information. He includes a simple Zend Framework-based script he's now using get the latest value from that table and execute only the migrations after that. The migrations are executed in order - he recommends using a timestamp or formatted date on the filename to set the order.

On the Ibuildings techPortal today Harrie Verveer has a new post looking at database version control - one of the more difficult topics for development groups - and some of the technology that can be used to help make it a bit simpler.

Database version control is something that most developers have to deal with regularly, yet only a few have actually thought about what solution might be best for them. Most people have a solution that sort of works for them, but when you ask them about the subject they are pretty convinced that there must be some better way to manage database changes, they're just not entirely sure what that solution is - but the silver bullet must be out there somewhere, right?

He starts where most developers start - their own custom script. It usually will take in a series of patch files and apply them one by one. In this case a "patch level" is stored somewhere (file/database) and is checked when the deployment is done. He points out a few issues with this method including patch naming issues and branching. Taking a step up the technology tree, he looks at other solutions like Phing+DBDeploy, Liquibase, and Doctrine migrations to try to help you find your project's "silver bullet".