PHP Classes

File: libs/Doctrine/UPGRADE_TO_2_0

Recommend this page to a friend!
  Classes of william amed   Raptor 2   libs/Doctrine/UPGRADE_TO_2_0   Download  
File: libs/Doctrine/UPGRADE_TO_2_0
Role: Auxiliary data
Content type: text/plain
Description: Auxiliary data
Class: Raptor 2
Framework that takes routes from annotations
Author: By
Last change:
Date: 7 years ago
Size: 9,167 bytes
 

Contents

Class file image Download
# 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.