[DDC-1195] The orm:convert-mapping is not configurable enough for Symfony2 Created: 05/Jun/11 Updated: 16/Aug/11 Resolved: 16/Aug/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.0.5 |
| Fix Version/s: | 2.0.7 |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Fabien Potencier | Assignee: | Guilherme Blanco |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
see https://github.com/symfony/symfony/issues/1119 fix here https://github.com/doctrine/doctrine2/pull/66 |
| Comments |
| Comment by Guilherme Blanco [ 16/Aug/11 ] |
|
Already fixed. |
[DDC-1302] orphan-removal does not work in XML Created: 29/Jul/11 Updated: 31/Jul/11 Resolved: 31/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | 2.1 |
| Fix Version/s: | 2.0.7, 2.1.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The check for $oneToManyElement-> {'orphan-removal'}returns false, the right check would be $oneToManyElement['orphan-removal'] |
| Comments |
| Comment by Benjamin Eberlei [ 31/Jul/11 ] |
|
Fixed and merged into 2.0.x and 2.1.x branches. |
[DDC-1276] Merging persistent collections broken if managed and merged collection are the same object Created: 13/Jul/11 Updated: 26/Jul/11 Resolved: 26/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.1 |
| Fix Version/s: | 2.0.7, 2.1.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Lienhart Woitok | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
FLOW3 |
||
| Description |
|
When FLOW3 maps request arguments to entities, it works on clones of the changed entities while entities, which are not affected by the request arguments stay the original objects. If the entity has a persistent collection which is not changed and therefore not cloned, the call to $repository->update() (which internally calls $em->merge()) eventually clears the $managedCol in $uow->doMerge() (line 1460 in current master), but if the $mergeCol is the same object, this is obviously wrong behavior as no related entities exist anymore in the entity to merge. Made up example code (not sure if this simple example works as I have no test setup I could use for it) /**
* @entity
* @scope prototype
*/
class A {}
/**
* @entity
* @scope prototype
*/
class B {
/**
* @var \Doctrine\Common\Collection\ArrayCollection<A>
* @ManyToMany
*/
public $relation;
}
$b = $repository->find(); // assume $b has some A in relation
$anotherB = clone $b;
$em->merge($anotherB);
After this relation of $b is empty |
| Comments |
| Comment by Benjamin Eberlei [ 26/Jul/11 ] |
|
Fixed |
[DDC-1240] Missing exception message Created: 01/Jul/11 Updated: 12/Jul/11 Resolved: 12/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.x |
| Fix Version/s: | 2.0.7, 2.1.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Yaroslav Zenin | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Message in constructor should be assigned to exception message Index: OptimisticLockException.php public function __construct($msg, $entity) { + $this->message = $msg; $this->entity = $entity; } |
| Comments |
| Comment by Benjamin Eberlei [ 12/Jul/11 ] |
|
Fixed |
[DDC-1257] Duplicate PHP methods generated from XML metadata lifecycle-callbacks Created: 08/Jul/11 Updated: 09/Jul/11 Resolved: 09/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.1 |
| Fix Version/s: | 2.0.7, 2.1.1, 2.2 |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Stephen Lang | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Zend Server 5.1.0, PHP 5.3.5, Apache 2.2.10, Linux (SUSE) |
||
| Description |
|
If lifecycle callbacks are added to XML metadata like so: <lifecycle-callbacks> <lifecycle-callback type="prePersist" method="validate" /> <lifecycle-callback type="preUpdate" method="validate" /> </lifecycle-callbacks> The validate() method will appear twice in an entity generated from this metadata. |
| Comments |
| Comment by Benjamin Eberlei [ 09/Jul/11 ] |
|
Fixed |
[DDC-1251] EntityGenerator uses non-existing constant T_AMPERSAND Created: 05/Jul/11 Updated: 09/Jul/11 Resolved: 09/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.1 |
| Fix Version/s: | 2.0.7, 2.1.1, 2.2 |
| Security Level: | All |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Jordi Boggiano | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Irrelevant |
||
| Description |
|
As per http://www.php.net/manual/en/tokens.php - the T_AMPERSAND token does not exist. I'm not sure what was the intent, but the entity generator fails on the following code: $elems = array_map(function($el) {
return $el;
}, $elems);
Due to the way notices are handled in Symfony, this basically stops the execution of the generator entirely. Not so great. [ErrorException] Notice: Use of undefined constant T_AMPERSAND - assumed 'T_AMPERSAND' in ./vendor/doctrine/lib/Doctrine/ORM/Tools/EntityGenerator.php line 454 Commenting out the offending line makes it work fine though, so I think it's just choking while expecting a function that takes args by reference or something. |
| Comments |
| Comment by Benjamin Eberlei [ 09/Jul/11 ] |
|
Fixed |
[DDC-1022] Wakeup behavior difference between proxy and eager-loaded instance Created: 09/Feb/11 Updated: 09/Jul/11 Resolved: 09/Jul/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.0.7, 2.1.1, 2.2 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Karsten Dambekalns | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
When an object is reconstituted from the persistent storage the unserialize trick is used. That means __wakeup() is called, which is useful to do further initialization as needed. If the object is lazy loaded a proxy is generated. That proxy is generated with new and thus no _wakeup() is called. When the proxy is eventually initialized still no call to _wakeup() is done, thus initialization code that is "usually" executed is not called when an object is lazy-loaded. That is a semantical error. |
| Comments |
| Comment by Benjamin Eberlei [ 26/Feb/11 ] |
|
__wakeup() shouldn't be used as per definition of an entity, http://www.doctrine-project.org/docs/orm/2.0/en/cookbook/implementing-wakeup-or-clone.html For post initialization "postLoad()" should be used. |
| Comment by Karsten Dambekalns [ 26/Feb/11 ] |
|
You write shouldn't be used, but that seems somewhat strange, given that the page you point to explicitly says However, it is quite easy to make use of these methods in a safe way by guarding the custom wakeup or clone code with an entity identity check, as demonstrated in the following sections. And still the issue remains that eager-loaded instances created with the unserialize trick do call wakeup() (of course) but this does not happen when being lazy-loaded. Inconsistency, it screams... |
| Comment by Benjamin Eberlei [ 09/Jul/11 ] |
|
I changed my mind, this is valid |
| Comment by Benjamin Eberlei [ 09/Jul/11 ] |
|
Fixed in 2.0.7, 2.1.1 and in master |
[DDC-1230] entity state is not set to STATE_REMOVED when removing an entity Created: 27/Jun/11 Updated: 28/Jun/11 Resolved: 28/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.0.7, 2.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Christophe Coevoet | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The UnitOfWork never sets the state to STATE_REMOVED in the map when scheduling an entity for delete. This means that the UnitOfWork will never tell you that the entity is in STATE_REMOVED when asking for its state but will return STATE_MANAGED |
| Comments |
| Comment by Benjamin Eberlei [ 28/Jun/11 ] |
|
Fixed |
[DDC-1224] QueryBuilder delete issues CREATE TEMPORARY TABLE error on PostgreSQL Created: 22/Jun/11 Updated: 26/Jun/11 Resolved: 26/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.1 |
| Fix Version/s: | 2.0.7, 2.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Rafael Kassner | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
PostgreSQL 8.4 |
||
| Description |
|
When I try to issue a delete an Class Table Inheritance Entity using QueryBuilder and I'm using schemas on tablename (for Postgres), I got the following error from postgres: SQLSTATE[42P16]: Invalid table definition: 7 ERROR: temporary tables cannot specify a schema name This occurs because Doctrine\ORM\Mapping\ClassMetadataInfo::getTemporaryIdTableName() returns just "$this->table['name'] . '_id_tmp'", and when my entity is declared with @Table(name="feed.tb_feed"), obviously I will got error. Temporary tables are created in a special schema in Postgres, and I'm thinking to convert the tablename from the class metadata from feed.tb_feed to feed_tb_feed into the getTemporaryIdTableName method with a single str_replace. That works for Postgres, but I don't mind what can happen in another DBMS. Any suggestions? |
| Comments |
| Comment by Benjamin Eberlei [ 26/Jun/11 ] |
|
Fixed |
[DDC-1211] Expr::literal problem with numeric value 0 Created: 16/Jun/11 Updated: 19/Jun/11 Resolved: 19/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.0.7, 2.1 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Gustavo Falco | Assignee: | Guilherme Blanco |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Apache 2.2.16 |
||
| Description |
|
Hi, I'm using master branch of Doctrine 2. Including an Expr with a numeric 0 value (not a string): $value = 0; $qb->expr()->gte($field, $qb->expr()->literal($value)); Expr::literal method will return an empty string ('') instead of '0', which causes that this expression be something like: entity.myField >= instead of: entity.miField >= '0'' This makes the query fail. Tracking the issue down I've found this on Expr\Base::add method: public function add($arg) { if ( ! empty($arg) || ($arg instanceof self && $arg->count() > 0)) { // If we decide to keep Expr\Base instances, we can use this check if ( ! is_string($arg)) { $class = get_class($arg); if ( ! in_array($class, $this->_allowedClasses)) { throw new \InvalidArgumentException("Expression of type '$class' not allowed in this context."); } } $this->_parts[] = $arg; } } The problem is that empty function returns true if you pass '0', so a call to Expr\Base::add would end on NOT adding '0' to $this->_parts array. That's why it finally returns ''. I wanted to make the fix for this but I'm having issues running the phing build task. Which are the steps to follow to run the tests? Running phing build task I get on the "test" task: Could not create task/type: 'nativephpunit'. Make sure that this class has been declared using taskdef / typedef. Thanks! |
| Comments |
| Comment by Benjamin Eberlei [ 19/Jun/11 ] |
|
Assigned to guilherme, i suppose we could change the !empty($arg) to $arg !== null ? |
| Comment by Benjamin Eberlei [ 19/Jun/11 ] |
|
Fixed |
[DDC-849] PersistentCollection::clear() doesn't clear the collection Created: 31/Oct/10 Updated: 19/Jun/11 Resolved: 19/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.7 |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Jáchym Toušek | Assignee: | Roman S. Borschel |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Environment: |
PHP 5.3.2 |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Clearing ManyToMany association doesn't work. I needed to clear the roles of the user (after form submit) and then add the checked roles. Also counting them doesn't work properly. See the clearRoles method in the attachment. //EDIT: Don't know if it's important but the association is bidirectional. |
| Comments |
| Comment by Roman S. Borschel [ 31/Oct/10 ] |
|
Can you provide more context, like the code that is using the entity? Thanks. |
| Comment by Jáchym Toušek [ 05/Nov/10 ] |
|
Code is something like this: <?php //$user is instance of UserEntity from the attachment $user->clearRoles(); //$role is instance of RoleEntity which is in bidirectional association wirth user //$role sometimes is one of those previously cleared (assume it is for this example) if (...) { $user->addRole($role); /* which calles this: public function addRole(RoleEntity $entity) { //contains method is false positive (the entity was removed by clear, but contains still returns TRUE) if (!$this->roles->contains($entity)) { $this->roles[] = $entity; } return $this; } */ } //$em is instance of EntityManager $em->flush(); ?> Ultimately count method returns wrong number and contains is false positive. I know that when i don't use the contains condition it works but that's not the point. |
| Comment by Benjamin Eberlei [ 13/Nov/10 ] |
|
Sorry, but isn't then PersistentCollection::remove() and ::contains() wrong not clear()? I think i have a good grasp on the issue and try to reproduce it. |
| Comment by Benjamin Eberlei [ 15/Nov/10 ] |
|
I added a testcase tests/Doctrine/Tests/ORM/Functional/Ticket/DDC849Test.php that shows everything is working correctly. I cannot reproduce your problem. Can you try to extend this phpunit testcase to show the failure? I downgrade to trivial and detach the issue from RC1 |
| Comment by Benjamin Eberlei [ 19/Jun/11 ] |
|
Duplicate to |
| Comment by Benjamin Eberlei [ 19/Jun/11 ] |
|
Fixed |
[DDC-1189] PersistentCollection::clear() does not cause the collection to be initialized Created: 02/Jun/11 Updated: 19/Jun/11 Resolved: 19/Jun/11 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.0.7 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Dave Keen | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
If clear() is called on an uninitialized PersistentCollection it needs to set the collection to be initialized. An example of where this can cause problems:
This can return a false positive if the entity was previously in the collection. |
| Comments |
| Comment by Benjamin Eberlei [ 19/Jun/11 ] |
|
Fixed. |