241 lines
9.0 KiB
Plaintext
241 lines
9.0 KiB
Plaintext
# Update from 2.0-BETA3 to 2.0-BETA4
|
|
|
|
## XML Driver <change-tracking-policy /> element demoted to attribute
|
|
|
|
We changed how the XML Driver allows to define the change-tracking-policy. The working case is now:
|
|
|
|
<entity change-tracking-policy="DEFERRED_IMPLICT" />
|
|
|
|
# Update from 2.0-BETA2 to 2.0-BETA3
|
|
|
|
## Serialization of Uninitialized Proxies
|
|
|
|
As of Beta3 you can now serialize uninitialized proxies, an exception will only be thrown when
|
|
trying to access methods on the unserialized proxy as long as it has not been re-attached to the
|
|
EntityManager using `EntityManager#merge()`. See this example:
|
|
|
|
$proxy = $em->getReference('User', 1);
|
|
|
|
$serializedProxy = serialize($proxy);
|
|
$detachedProxy = unserialized($serializedProxy);
|
|
|
|
echo $em->contains($detachedProxy); // FALSE
|
|
|
|
try {
|
|
$detachedProxy->getId(); // uninitialized detached proxy
|
|
} catch(Exception $e) {
|
|
|
|
}
|
|
$attachedProxy = $em->merge($detachedProxy);
|
|
echo $attackedProxy->getId(); // works!
|
|
|
|
## Changed SQL implementation of Postgres and Oracle DateTime types
|
|
|
|
The DBAL Type "datetime" included the Timezone Offset in both Postgres and Oracle. As of this version they are now
|
|
generated without Timezone (TIMESTAMP WITHOUT TIME ZONE instead of TIMESTAMP WITH TIME ZONE).
|
|
See [this comment to Ticket DBAL-22](http://www.doctrine-project.org/jira/browse/DBAL-22?focusedCommentId=13396&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_13396)
|
|
for more details as well as migration issues for PostgreSQL and Oracle.
|
|
|
|
Both Postgres and Oracle will throw Exceptions during hydration of Objects with "DateTime" fields unless migration steps are taken!
|
|
|
|
## Removed multi-dot/deep-path expressions in DQL
|
|
|
|
The support for implicit joins in DQL through the multi-dot/Deep Path Expressions
|
|
was dropped. For example:
|
|
|
|
SELECT u FROM User u WHERE u.group.name = ?1
|
|
|
|
See the "u.group.id" here is using multi dots (deep expression) to walk
|
|
through the graph of objects and properties. Internally the DQL parser
|
|
would rewrite these queries to:
|
|
|
|
SELECT u FROM User u JOIN u.group g WHERE g.name = ?1
|
|
|
|
This explicit notation will be the only supported notation as of now. The internal
|
|
handling of multi-dots in the DQL Parser was very complex, error prone in edge cases
|
|
and required special treatment for several features we added. Additionally
|
|
it had edge cases that could not be solved without making the DQL Parser
|
|
even much more complex. For this reason we will drop the support for the
|
|
deep path expressions to increase maintainability and overall performance
|
|
of the DQL parsing process. This will benefit any DQL query being parsed,
|
|
even those not using deep path expressions.
|
|
|
|
Note that the generated SQL of both notations is exactly the same! You
|
|
don't loose anything through this.
|
|
|
|
## Default Allocation Size for Sequences
|
|
|
|
The default allocation size for sequences has been changed from 10 to 1. This step was made
|
|
to not cause confusion with users and also because it is partly some kind of premature optimization.
|
|
|
|
# Update from 2.0-BETA1 to 2.0-BETA2
|
|
|
|
There are no backwards incompatible changes in this release.
|
|
|
|
# Upgrade from 2.0-ALPHA4 to 2.0-BETA1
|
|
|
|
## EntityRepository deprecates access to protected variables
|
|
|
|
Instead of accessing protected variables for the EntityManager in
|
|
a custom EntityRepository it is now required to use the getter methods
|
|
for all the three instance variables:
|
|
|
|
* `$this->_em` now accessible through `$this->getEntityManager()`
|
|
* `$this->_class` now accessible through `$this->getClassMetadata()`
|
|
* `$this->_entityName` now accessible through `$this->getEntityName()`
|
|
|
|
Important: For Beta 2 the protected visibility of these three properties will be
|
|
changed to private!
|
|
|
|
## Console migrated to Symfony Console
|
|
|
|
The Doctrine CLI has been replaced by Symfony Console Configuration
|
|
|
|
Instead of having to specify:
|
|
|
|
[php]
|
|
$cliConfig = new CliConfiguration();
|
|
$cliConfig->setAttribute('em', $entityManager);
|
|
|
|
You now have to configure the script like:
|
|
|
|
[php]
|
|
$helperSet = new \Symfony\Components\Console\Helper\HelperSet(array(
|
|
'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
|
|
'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
|
|
));
|
|
|
|
## Console: No need for Mapping Paths anymore
|
|
|
|
In previous versions you had to specify the --from and --from-path options
|
|
to show where your mapping paths are from the console. However this information
|
|
is already known from the Mapping Driver configuration, so the requirement
|
|
for this options were dropped.
|
|
|
|
Instead for each console command all the entities are loaded and to
|
|
restrict the operation to one or more sub-groups you can use the --filter flag.
|
|
|
|
## AnnotationDriver is not a default mapping driver anymore
|
|
|
|
In conjunction with the recent changes to Console we realized that the
|
|
annotations driver being a default metadata driver lead to lots of glue
|
|
code in the console components to detect where entities lie and how to load
|
|
them for batch updates like SchemaTool and other commands. However the
|
|
annotations driver being a default driver does not really help that much
|
|
anyways.
|
|
|
|
Therefore we decided to break backwards compability in this issue and drop
|
|
the support for Annotations as Default Driver and require our users to
|
|
specify the driver explicitly (which allows us to ask for the path to all
|
|
entities).
|
|
|
|
If you are using the annotations metadata driver as default driver, you
|
|
have to add the following lines to your bootstrap code:
|
|
|
|
$driverImpl = $config->newDefaultAnnotationDriver(array(__DIR__."/Entities"));
|
|
$config->setMetadataDriverImpl($driverImpl);
|
|
|
|
You have to specify the path to your entities as either string of a single
|
|
path or array of multiple paths
|
|
to your entities. This information will be used by all console commands to
|
|
access all entities.
|
|
|
|
Xml and Yaml Drivers work as before!
|
|
|
|
|
|
## New inversedBy attribute
|
|
|
|
It is now *mandatory* that the owning side of a bidirectional association specifies the
|
|
'inversedBy' attribute that points to the name of the field on the inverse side that completes
|
|
the association. Example:
|
|
|
|
[php]
|
|
// BEFORE (ALPHA4 AND EARLIER)
|
|
class User
|
|
{
|
|
//...
|
|
/** @OneToOne(targetEntity="Address", mappedBy="user") */
|
|
private $address;
|
|
//...
|
|
}
|
|
class Address
|
|
{
|
|
//...
|
|
/** @OneToOne(targetEntity="User") */
|
|
private $user;
|
|
//...
|
|
}
|
|
|
|
// SINCE BETA1
|
|
// User class DOES NOT CHANGE
|
|
class Address
|
|
{
|
|
//...
|
|
/** @OneToOne(targetEntity="User", inversedBy="address") */
|
|
private $user;
|
|
//...
|
|
}
|
|
|
|
Thus, the inversedBy attribute is the counterpart to the mappedBy attribute. This change
|
|
was necessary to enable some simplifications and further performance improvements. We
|
|
apologize for the inconvenience.
|
|
|
|
## Default Property for Field Mappings
|
|
|
|
The "default" option for database column defaults has been removed. If desired, database column defaults can
|
|
be implemented by using the columnDefinition attribute of the @Column annotation (or the approriate XML and YAML equivalents).
|
|
Prefer PHP default values, if possible.
|
|
|
|
## Selecting Partial Objects
|
|
|
|
Querying for partial objects now has a new syntax. The old syntax to query for partial objects
|
|
now has a different meaning. This is best illustrated by an example. If you previously
|
|
had a DQL query like this:
|
|
|
|
[sql]
|
|
SELECT u.id, u.name FROM User u
|
|
|
|
Since BETA1, simple state field path expressions in the select clause are used to select
|
|
object fields as plain scalar values (something that was not possible before).
|
|
To achieve the same result as previously (that is, a partial object with only id and name populated)
|
|
you need to use the following, explicit syntax:
|
|
|
|
[sql]
|
|
SELECT PARTIAL u.{id,name} FROM User u
|
|
|
|
## XML Mapping Driver
|
|
|
|
The 'inheritance-type' attribute changed to take last bit of ClassMetadata constant names, i.e.
|
|
NONE, SINGLE_TABLE, INHERITANCE_TYPE_JOINED
|
|
|
|
## YAML Mapping Driver
|
|
|
|
The way to specify lifecycle callbacks in YAML Mapping driver was changed to allow for multiple callbacks
|
|
per event. The Old syntax ways:
|
|
|
|
[yaml]
|
|
lifecycleCallbacks:
|
|
doStuffOnPrePersist: prePersist
|
|
doStuffOnPostPersist: postPersist
|
|
|
|
The new syntax is:
|
|
|
|
[yaml]
|
|
lifecycleCallbacks:
|
|
prePersist: [ doStuffOnPrePersist, doOtherStuffOnPrePersistToo ]
|
|
postPersist: [ doStuffOnPostPersist ]
|
|
|
|
## PreUpdate Event Listeners
|
|
|
|
Event Listeners listening to the 'preUpdate' event can only affect the primitive values of entity changesets
|
|
by using the API on the `PreUpdateEventArgs` instance passed to the preUpdate listener method. Any changes
|
|
to the state of the entitys properties won't affect the database UPDATE statement anymore. This gives drastic
|
|
performance benefits for the preUpdate event.
|
|
|
|
## Collection API
|
|
|
|
The Collection interface in the Common package has been updated with some missing methods
|
|
that were present only on the default implementation, ArrayCollection. Custom collection
|
|
implementations need to be updated to adhere to the updated interface.
|
|
|