I am developing a web application using Zend Framework 2 and Doctrine 2. I'm new to Doctrine 2 in general and Migrations in particular. I was wondering if there are any recommended best practices in using this. Some specific things I'm looking for:
A recommended workflow from development to deployment?
Do you include pre-populating data in migrations?
How to handle reverting to a previous version if migration fails.
Many thanks!
Doctrine has own library for migrations, that includes also Symfony bundle.
For Zend there probably is some bundle as well (maybe seek on Github a bit more)
As for your specific questions:
Nothing special. Basic workflow is nicely described in Symfony bundle documentation. We use it in pretty same way even in a different framework.
Yes, so every developer has fully operational system. For tests we use data-fixtures with minimal required data only.
It's managed by this package itself.
The Doctrine ORM module for ZF2 (DoctrineORMModule) has built-in support for Doctrine ORM migrations. There's a very brief blurb in the documentation about how to configure it. You can then access the migration commands (generate, migrate, etc) through the CLI interface that module provides (vendor/bin/doctrine-module)
As for my personal workflow I generally put initialization or pre-population data - the stuff you initially seed a new installation with - into database fixtures (which Doctrine ORM also supports and there is a ZF2 module for).
Related
I wonder if there is an interface that diverse ORM should implement for Symfony or not.
The question came up when I was building a service that accepts an ORM (Doctrine right now), and wanted to declare type.
I guess different ORM have different behaviour and classes... in those cases, how can build entities that do not depend on specific ORM in case one wants to switch later?
Generally, Symfony is agnostic in regard to your choice of ORM.
The standard edition comes bundled with Doctrine and also contains some “bridge” code to ease the integration.
However, you can use any ORM you’d like to. For example, Propel is known to work well with Symfony, too. The Propel team also maintains an integration bundle.
There is no “interface” in the sense of a formal description an ORM has to comply with. There is no such thing as interface SymfonyOrmInterface {}.
Think about it, how and why should Symfony demand this? Symfony is a HTTP framework built on a set of loosely coupled components. Most of these components don’t even know what an ORM is or if one is currently available in the application.
You will usually install your ORM through composer, and it will be available in your business code (assuming that it supports autoloading with PSR-0/-4).
Of course, for a proper integration of an ORM into Symfony, there are some conventions and features, such as:
CLI commands, e.g. for schema updates,
Managing configuration values through the global config.yml and parameters.yml files,
Providing services and dependencies through Dependency Injection.
These are implemented in integration bundles, usually provided by the respective ORM vendor.
For your business code, this means that you can’t just replace one ORM with another one. There are significant differences accross ORMs in regard to storage abstraction, caching, querying, hydration, etc. Replacing an ORM will always require you to adapt your business logic to some exent, and not only in a Symfony project.
Is the Doctrine Migrations project compatible with Doctrine MongoDB?
It isn't clear to me from searching and looking at the Doctrine Migrations project whether it is compatible with ODM solutions (e.g. MongoDB) as well as ORM solutions.
If it is, can anyone suggest examples or articles on how to use the two together?
If it isn't, are there reasonable alternatives?
Question Background:
I understand, marginally, the different approaches to migrating a document's data from one version of the document to another and the pros and cons of each.
I am leaning towards possibly implementing a hybrid approach of gradual schema changes and migration scripts as suggested here. Leveraging the functionality within Doctrine's MongoDB library written about by Jonathan Wage in his post: Doctrine MongoDB ODM Schema Migrations.
Even with that, I need to find some way of creating a migration script or performing the data migration, and Doctrine Migrations seemed like a good first choice.
As an aside, another user warns against using the approach Jonathan Wage presents above for migrating data and instead running commands (JavaScript?) directly against the database.
Despite doctrine-migrations is not compabible with MongoDB ODM (it only supports DBAL) you can bet for the alternative mongo-based migration components made by 3rd party teams.
It was firstly developed here https://github.com/antimattr/mongodb-migrations
but after it has been abandoned the project continues here https://github.com/doesntmattr/mongodb-migrations
Ufortunately, it isn't compatible with ODM. It supports ORM only.
What is the procedure to install an ORM component such as Doctrine into an existing custom PHP5 MVC framework?
What are the minimal requirement in terms of framework architecture and fonctionalities ?
What are the possible problems to face ?
Would it be problematic to have side by side tables generated by the ORM and some by "old fashioned " SQL request?
The ORM is simply an abstraction for your database interactions. The Doctrine ORM wraps PHPs PDO library and adds some useful abstractions. To implement Doctrine into your existing framework you'll need to download the code and put it into a directory in your project. If you're already using third party libraries, place it there. If not, create a vendors directory and drop doctrine in it. You can follow the Doctrine documentation for installation and configuration details.
Once you've implemented doctrine, your task will be to update existing database interactions. If all database interactions are already handled through models, you should be able to write an abstract or interface base class for your models. From there, models can be updated to implement Doctrine methods for interaction.
If you have SQL scattered around the app, you should probably decouple the database interactions and isolate them into models then follow the process described above.
There is nothing about using the ORM that will prevent existing database interactions from operating, but that is very messy and should be avoided if at all possible.
I have to migrate an application from Zend Framework 1.12.0 to version 2. There seem to be no migration guides yet. I have already studied ZF2 coding conventions and I adopted dependency injection (Zend\Di) and PHP 5.3 namespaces. My goal is to refactor my ZF1 application into a ZF2 module.
Question: Is it possible to proceed step-by-step with an at least partly working application after every step and avoid huge refactoring steps? If yes, what are the steps?
Here's my idea of such a step-by-step migration, but I don't know if I end up with a working application after every step:
Start by setting up the ZF2 Skeleton Application
Set up a new module (MyApp) and reorganize the contents of my ZF1 application into the MyApp module folder structure. Then set up very basic configuration and bootstrapping and migrate the IndexController by extending it from the ZF2 AbstractActionController. The models (Zend_Db) and views (Zend_View) will be migrated later. The goal here is to have a working IndexController::indexAction which doesn't have many dependencies.
Set up more configuration and bootstrapping (Routing, Translate, Locale, Cache, Db, Acl, ViewHelpers, ...). I'd like to set up the ZF1 versions of these components first and migrate them later one by one.
Migrate the other controllers and set up dependency injection into the controllers either with Zend\Di or by using the ServiceManager.
Set up automatic deployment by making the old phing scripts work with the new directory structure.
Migrate the views (including helpers) and forms to ZF2.
Migrate the models (from Zend_Db either to ZF2 Zend\Db or to Doctrine).
Migrate other ZF1 components one by one (Translate, Locale, Cache, Acl, ...).
Refactoring rehab and long holiday.
However, I will have a workin application after every step only if certain ZF2 components work together with ZF1 components. I have no idea if it's e.g. possible to use ZF1 views (and view helpers) with ZF2 controllers.
Migration from Zend Framework 1
This guide is intended to provide tools and strategies for migrating from Zend Framework 1 to Zend Framework 2. There is no single solution that will work for every project, nor any tools to automate the process.
In this guide, we will cover the following:
Tools for namespacing your code.
Tools for consuming Zend Framework 2 within your Zend Framework 1 application.
Strategies for running Zend Framework 2 and Zend Framework 1 in parallel.
Strategies for making your code easier to migrate, focussing primarily on clean separation of your domain logic and the MVC layer.
Strategies for migrating the MVC layer.
Strategies for migrating your domain layer.
http://framework.zend.com/manual/2.1/en/migration/overview.html
Somewhere it was once written that it will be easy peasy with some intermediate layer but I never saw any links or anything in the library that looked just remotely like it.
Now the only thing and latest information you can find is in the documentation's Overview page. It is this:
Note ZF2 is not backward compatible with ZF1, because of the new features in PHP 5.3+ implemented by the framework, and due to major rewrites of many components.
I never expected it to be backwards compatible but the key statement here I believe is the major rewrites of many components.
I've started a new project with ZF2 a few months ago where I only wanted the library; so no MVC which should be easy, right? So far it's been pretty much a nightmare because nothing is the same anymore. Besides some familiar class names or structures the whole framework has been completely rewritten from the ground up.
Things I loved, used a lot and knew by heart like forms, cache or session are completely different. For my project it has cost me a lot of time with no benefit. One of the key objects for ZF2 I thought was overhaul the documentation which is as of these written way worse than the previous one.
For my other existing ZF1.x projects I don't see how to manage an upgrade except to completely rewrite the application.
From the Zend Framework 2 FAQ:
I have an application built with Zend Framework 1 – will I be able to migrate it to the new version?
Absolutely. An important part of Zend Framework 2 is the migration layer that will allow ZF 1 code to run on the new ZF 2 engine, which will be made available in the future. With it, you will be able to add new ZF 2 code, and refactor existing code, at a controlled pace.
However, at this point, I have not heard of any actual migration layer. We can only hope there will be, but at this point, I have my doubts.
We have been migrating a large application from Zend Framework 1 to Zend Framework 2 over the past year. We started out with simple things like namespacing, and slowly worked our way into the various library components. Ultimately, we ended up editing Zend_Layout to work with Zend\Filter, Zend_Form to work with Zend\Filter and Zend\Json, Zend_Navigation to work with Zend\Permissions\Acl, etc. This helped us to eliminate almost all ZF1 components with the exception of the ZF1 application structure which includes four classes Zend_Application, Zend_Config, Zend_Controller, and Zend_Layout. The final piece of the puzzle is the implementation of Zend\Mvc\Application and Zend\View, the remainder is ZF2-ready.
Most recently, we created a proxy of sorts to hook into Zend\Mvc\Application and ZF2 modules from ZF1. This has been extremely helpful. I detailed the steps over at http://webjawns.com/2013/11/migrating-to-zf2-integrating-composer-and-doctrineormmodule/.
In summary...
Convert prefixes to namespaces (Model_ to Model\, Application_Controller to Application\Controller, etc.)
Replace non-MVC components with ZF2 counterparts including autoloader
Create ZF2 application structure and hooks to begin utilizing ZF2 modules
Move controllers and views (still working on a plan for this one)
I am about to start a project on PHP and selected Codeigniter as a framework to be used after receiving lot of plus comments from Codeigniter-users ;-)
I am not much clear about which ORM to be used with codeigniter. I was advised to use Doctrine. Is there any tool available for codeigniter to create models and db mapping with Doctrine on command line?
You can use Doctrine itself for creating models. Follow the cookbook
http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/code-igniter-and-doctrine/en
to setup, so then in /application/ you can use
$ ./doctrine [command]
to create models and mappings.
Note: in this moment I'm failing to access any page at the doctrine-project.org site. May be later...