89 lines
4.9 KiB
Plaintext
89 lines
4.9 KiB
Plaintext
> **NOTE**
|
|
> This document does not describe how to upgrade from Doctrine 1.x to Doctrine 2 as this is a more
|
|
> complicated process.
|
|
|
|
# Upgrade from 2.0-ALPHA4 to 2.0 ...
|
|
|
|
## Default Property for Field Mappings removed
|
|
|
|
The "default" option for database column defaults has been removed. If desired database column defaults can
|
|
be implemented by using the @columnDefinition annotation (or the approriate XML and YAML equivalents).
|
|
|
|
Additionally keep in mind that Doctrine's focus in on objects and you can specifiy default values for an Entitiy's
|
|
mapped fields inside PHP easily. Upon persist() invocation these values are saved as if they were default values.
|
|
|
|
# Upgrade from 2.0-ALPHA3 to 2.0-ALPHA4
|
|
|
|
## CLI Controller changes
|
|
|
|
CLI main object changed its name and namespace. Renamed from Doctrine\ORM\Tools\Cli to Doctrine\Common\Cli\CliController.
|
|
Doctrine\Common\Cli\CliController now only deals with namespaces. Ready to go, Core, Dbal and Orm are available and you can subscribe new tasks by retrieving the namespace and including new task. Example:
|
|
|
|
[php]
|
|
$cli->getNamespace('Core')->addTask('my-example', '\MyProject\Tools\Cli\Tasks\MyExampleTask');
|
|
|
|
|
|
## CLI Tasks documentation
|
|
|
|
Tasks have implemented a new way to build documentation. Although it is still possible to define the help manually by extending the basicHelp and extendedHelp, they are now optional.
|
|
With new required method AbstractTask::buildDocumentation, its implementation defines the TaskDocumentation instance (accessible through AbstractTask::getDocumentation()), basicHelp and extendedHelp are now not necessary to be implemented.
|
|
|
|
## Changes in Method Signatures
|
|
|
|
* A bunch of Methods on both Doctrine\DBAL\Platforms\AbstractPlatform and Doctrine\DBAL\Schema\AbstractSchemaManager
|
|
have changed quite significantly by adopting the new Schema instance objects.
|
|
|
|
## Renamed Methods
|
|
|
|
* Doctrine\ORM\AbstractQuery::setExpireResultCache() -> expireResultCache()
|
|
* Doctrine\ORM\Query::setExpireQueryCache() -> expireQueryCache()
|
|
|
|
## SchemaTool Changes
|
|
|
|
* "doctrine schema-tool --drop" now always drops the complete database instead of
|
|
only those tables defined by the current database model. The previous method had
|
|
problems when foreign keys of orphaned tables pointed to tables that were schedulded
|
|
for deletion.
|
|
* Use "doctrine schema-tool --update" to get a save incremental update for your
|
|
database schema without deleting any unused tables, sequences or foreign keys.
|
|
* Use "doctrine schema-tool --complete-update" to do a full incremental update of
|
|
your schema.
|
|
|
|
|
|
# Upgrade from 2.0-ALPHA2 to 2.0-ALPHA3
|
|
|
|
This section details the changes made to Doctrine 2.0-ALPHA3 to make it easier for you
|
|
to upgrade your projects to use this version.
|
|
|
|
## CLI Changes
|
|
|
|
The $args variable used in the cli-config.php for configuring the Doctrine CLI has been renamed to $globalArguments.
|
|
|
|
## Proxy class changes
|
|
|
|
You are now required to make supply some minimalist configuration with regards to proxy objects. That involves 2 new configuration options. First, the directory where generated proxy classes should be placed needs to be specified. Secondly, you need to configure the namespace used for proxy classes. The following snippet shows an example:
|
|
|
|
[php]
|
|
// step 1: configure directory for proxy classes
|
|
// $config instanceof Doctrine\ORM\Configuration
|
|
$config->setProxyDir('/path/to/myproject/lib/MyProject/Generated/Proxies');
|
|
$config->setProxyNamespace('MyProject\Generated\Proxies');
|
|
|
|
Note that proxy classes behave exactly like any other classes when it comes to class loading. Therefore you need to make sure the proxy classes can be loaded by some class loader. If you place the generated proxy classes in a namespace and directory under your projects class files, like in the example above, it would be sufficient to register the MyProject namespace on a class loader. Since the proxy classes are contained in that namespace and adhere to the standards for class loading, no additional work is required.
|
|
Generating the proxy classes into a namespace within your class library is the recommended setup.
|
|
|
|
Entities with initialized proxy objects can now be serialized and unserialized properly from within the same application.
|
|
|
|
For more details refer to the Configuration section of the manual.
|
|
|
|
## Removed allowPartialObjects configuration option
|
|
|
|
The allowPartialObjects configuration option together with the `Configuration#getAllowPartialObjects` and `Configuration#setAllowPartialObjects` methods have been removed.
|
|
The new behavior is as if the option were set to FALSE all the time, basically disallowing partial objects globally. However, you can still use the `Query::HINT_FORCE_PARTIAL_LOAD` query hint to force a query to return partial objects for optimization purposes.
|
|
|
|
## Renamed Methods
|
|
|
|
* Doctrine\ORM\Configuration#getCacheDir() to getProxyDir()
|
|
* Doctrine\ORM\Configuration#setCacheDir($dir) to setProxyDir($dir)
|
|
|