[DDC-3137] Entity Repository Interface Fatal Error Created: 24/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: 2.x
Security Level: All

Type: Bug Priority: Critical
Reporter: Aleksandr Yulin Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: orm
Environment:

ZF2 + Doctrine 2



 Description   

For example:
$em = $this->getServiceLocator()->get('doctrine.entitymanager.orm_default');
$em->getRepository('MyEntity');

Response:
Fatal error: Class Doctrine\ORM\Repository\DefaultRepositoryFactory contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Doctrine\ORM\Repository\RepositoryFactory::xgetRepository) in /srv/www/casestories.loc/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php on line 77



 Comments   
Comment by Aleksandr Yulin [ 24/May/14 ]

composer update problem, sorry, close issue





[DDC-2602] Unable to query for entities on postLoad event Created: 07/Aug/13  Updated: 19/Aug/13  Resolved: 19/Aug/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: Git Master
Fix Version/s: 2.x, Git Master
Security Level: All

Type: Bug Priority: Major
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Guilherme Blanco [ 19/Aug/13 ]

implemented fix





[DDC-1774] [GH-334] Command fixes Created: 11/Apr/12  Updated: 04/May/12  Resolved: 04/May/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.x
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hhamon:

Url: https://github.com/doctrine/doctrine2/pull/334

Message:

This patch can be backported on all branches.



 Comments   
Comment by Benjamin Eberlei [ 11/Apr/12 ]

A related Github Pull-Request [GH-334] was closed
https://github.com/doctrine/doctrine2/pull/334





[DDC-1598] ProxyFactory makes assumptions on identifier getter code Created: 13/Jan/12  Updated: 16/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2-BETA1, 2.2-BETA2, Git Master
Fix Version/s: 2.2, 2.3, 2.x
Security Level: All

Type: Bug Priority: Critical
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

As of
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L214
and
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L237
the current ProxyFactory isn't actually checking if the identifier getter has logic in it.
Current checks aren't enough/valid.

In my opinion the check should be matching following:

(public|protected)\s+function\s+getFieldname\s*(\s*)\s+

{\s*\$this\s*->Fieldname\s*;\s*}

Not really experienced with regex, but currently cannot come up with a more secure check.



 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

Can you explain why you think this is necessary?

You are right an id method with logic could exist in 4 lines of code, but for what purpose?

Comment by Marco Pivetta [ 15/Jan/12 ]

First of all it is a question of concept. Doctrine shouldn't assume anything about entities outside of their fields. It already introduces a level of complication when we explain how to clone/serialize objects, which was very confusing.

Asking for the purpose of an identifier field getter method is in my opinion again an attempt of making assumptions over user's code...

What if the user wrote something like:

public function getIdentifierField1()

{ return $this->identifierField1? $this->_myInitializationStuff() : null; }

private function _myInitializationStuff()

{ //open files, check stuff, make things difficult for the D2 team :D }

For instance, opening file handlers, sockets, whatever... This is a case that would break the entity because of optimization introduced by the ProxyFactory. (not to mention when getIdentifierField1 does some conversion, like return $this->identifierField1 + self::OFFSET_REQUIRED_BY_WEBSERVICE;

I'm not arguing about the validity of this optimization, but that the checks are too lazy.

I've read something about moving the ProxyFactory to common and using code scanner tools, and the check should be about applying the optimization only when the form is

return $this->identifierField1;

That's why I put the example of the regex. That would probably not be as safe as using some reflection-based tool, but surely more than just checking if the code is <= 4 lines...

Comment by Marco Pivetta [ 15/Jan/12 ]

Also don't know what stuff like EAccelerator (known in this Jira as of it's fantastic idea about stripping comments) would make the check of the 4 lines like.

Comment by Benjamin Eberlei [ 16/Jan/12 ]

This argument is void i just seen

A method:

public function getIdentifierField1()
{
   return $this->identifierField1? $this->_myInitializationStuff() : null;
} 

Will only used when the id is not set anyways.

In any other case Ids are Immutable and changing them in your code would break a lot more than just this smart proxy method generation.

Comment by Marco Pivetta [ 16/Jan/12 ]

Nope, this code actually works only if the ID is set
I'm not talking about changing IDs, it's just that getters and setters don't always reflect the class attributes...

Comment by Marco Pivetta [ 16/Jan/12 ]

As of IRC there's 3 ways (for now) to get this solved:

  • Some code scanner/stronger checks (difficult/problems with private methods/slow)
  • Regex (as of description)
  • Adding configuration (per-entity or per-method. Probably too messy)
  • Documenting it as "magic" of proxies and let the users be aware of it




[DDC-1521] No way reuse parameters in custom function twice Created: 07/Dec/11  Updated: 16/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.1.1
Fix Version/s: 2.x
Security Level: All

Type: Bug Priority: Major
Reporter: Konstantin Assignee: Guilherme Blanco
Resolution: Invalid Votes: 1
Labels: None
Environment:

sf2



 Description   

There is custom function:

class DistanceFunction extends FunctionNode
{
	protected $fromLat;
	protected $fromLng;
	protected $toLat;
	protected $toLng;

	public function parse(\Doctrine\ORM\Query\Parser $parser)
	{
		$parser->match(Lexer::T_IDENTIFIER);
		$parser->match(Lexer::T_OPEN_PARENTHESIS);

		$this->fromLat = $parser->ArithmeticPrimary();
		$parser->match(Lexer::T_COMMA);

		$this->fromLng = $parser->ArithmeticPrimary();
		$parser->match(Lexer::T_COMMA);

		$this->toLat = $parser->ArithmeticPrimary();
		$parser->match(Lexer::T_COMMA);

		$this->toLng = $parser->ArithmeticPrimary();

		$parser->match(Lexer::T_CLOSE_PARENTHESIS);
	}

	public function getSql(\Doctrine\ORM\Query\SqlWalker $sqlWalker)
	{
		$fromLat = $this->fromLat->dispatch($sqlWalker);
		$fromLng = $this->fromLng->dispatch($sqlWalker);
		$toLat = $this->toLat->dispatch($sqlWalker);
		$toLng = $this->toLng->dispatch($sqlWalker);

		$earthDiameterInKM = 1.609344 * 3956 * 2;

		$sql = "($earthDiameterInKM * ASIN(SQRT(POWER(" .
			"SIN(($fromLat - ABS($toLat)) * PI() / 180 / 2), 2) + " .
			"COS($fromLat * PI() / 180) * COS(ABS($toLat) * PI() / 180) * " .
			"POWER(SIN(($fromLng - $toLng) * PI() / 180 / 2), 2) " .
			")))";

//echo $sql;

		return $sql;
	}

and the usage of it

$em
	->createQuery('SELECT DISTANCE(a.latitude, a.longitude, :lat, :lng) FROM Ololo:AbstractArea a WHERE a = 2')
	->setParameter('lat', 1)
	->setParameter('lng', 2)
	->getResult();

what this function generate:

(12733.129728 * ASIN(SQRT(POWER(SIN((t0_.latitude - ABS(?)) * PI() / 180 / 2), 2) + COS(t0_.latitude * PI() / 180) * COS
(ABS(?) * PI() / 180) * POWER(SIN((t0_.longitude - ?) * PI() / 180 / 2), 2) )))

and exception raised: "SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens"

Don't know, does it affects on master branch (does they support native named parameters?).



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Issue cannot be reproduced on master.
Marking ticket as "cannot reproduce".

Added coverage on this commit: https://github.com/doctrine/doctrine2/commit/f6eb83705adc9603a87e8d194aa7f29e8ab36ebe

Comment by Guilherme Blanco [ 20/Dec/11 ]

Ok, it seems this is only reproduceable on MySQL and PgSQL.

Reopening and trying a fix.

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version

Comment by Guilherme Blanco [ 16/Jan/12 ]

This issue is invalid.

Whenever you want to point to an InputParameter, you have to call the dispatch() function.
Unfortunately, you cannot assign to a variable and reuse it freely. That way, Doctrine would only be notified once about the existence of a parameter, while actually you'd be using in multiple places.

The funny part is that pdo_sqlite addresses the issue internally, but other drivers don't. That was why I was unable to verify the issue in the first time.





[DDC-1505] EntityManager->find returning null for entity on the inverse side of a OneToOne association Created: 23/Nov/11  Updated: 18/Dec/11  Resolved: 18/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: 2.x, Git Master

Type: Bug Priority: Critical
Reporter: Chris Richard Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None


 Description   

BasicEntityPersister.getJoinSQLForJoinColumns treats joinColumn nullable setting as defaulting to false:

if(isset($joinColumn['nullable']) && $joinColumn['nullable'])

{ return 'LEFT JOIN'; }

I think it should be:

if(!isset($joinColumn['nullable']) || $joinColumn['nullable']){ return 'LEFT JOIN'; }

 Comments   
Comment by Benjamin Eberlei [ 15/Dec/11 ]

Assigned to asm

Comment by Benjamin Eberlei [ 18/Dec/11 ]

This issue is referenced in Github Pull-Request GH-226
https://github.com/doctrine/doctrine2/pull/226

Comment by Alexander [ 18/Dec/11 ]

Should be fixed as soon as this is pulled:
https://github.com/doctrine/doctrine2/pull/226

Comment by Benjamin Eberlei [ 18/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/226





[DDC-1265] Evaluate skip operations / loading through events Created: 09/Jul/11  Updated: 06/Sep/11  Resolved: 06/Sep/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 2.x
Security Level: All

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Comments   
Comment by Benjamin Eberlei [ 06/Sep/11 ]

Duplicate of DDC-17





[DDC-821] Consider adding Query-Join as another join method for DQL Created: 29/Sep/10  Updated: 30/Jul/13  Resolved: 30/Jul/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 2.x
Security Level: All

Type: New Feature Priority: Major
Reporter: Marc Hodgins Assignee: Guilherme Blanco
Resolution: Fixed Votes: 2
Labels: None


 Description   

Some ORM systems support an alternative to fetch-join queries, called a "query-join". See http://www.avaje.org/ebean/introquery_joinquery.html.

A query-join accomplishes the same as a fetch-join (hydrating a larger object graph across all associations types) but executes more than one SQL query in sequence in order to hydrate the requested portions of the graph in a result set. The first query retrieves data from the base entity/table and the next queries retrieve the data for the requested associations.

In some cases this approach is more efficient to a fetch-join:

(1) No data duplication in the SQL result as occurs in a fetch-join on to-many associations. Instead, this data is loaded through a second query. This saves network traffic, memory and general overhead in hydrating the returned results. In the case where large TEXT data is included in result sets, the savings here may be substantial.

(2) setFirstResult() and setMaxResult() are again effective (for pagination) and more importantly more efficient on these query-joins. The current DoctrineExtension solution to enable pagination on fetch-joins requires a series of queries to determine the target primary keys of the root entity of the query. The primary key lookup query requires DISTINCT or GROUP BY – which often triggers filesorts, temporary tables, etc (at least on MySQL) and greatly slows down the query. Query joins would not require this.

Possible implementation example:

// existing fetch-join
$query = $em->createQuery('SELECT c, o FROM Customers c JOIN c.orders o');
$query->setFirstResult(10)->setMaxResult(20); // doesn't do what you'd hope it would do, no ability to use this for pagination
$customersAndOrders = $query->getResult(); // array of Customer objects with Orders hydrated

// proposed query-join
$query = $em->createQuery('SELECT c, o FROM Customers c QUERY JOIN c.orders o');
$query->setFirstResult(10)->setMaxResult(20); // now works for pagination
$customersAndOrders = $query->getResult(); // array of Customer objects with Orders hyrdated
// this would execute a series of queries -- i.e. in SQL
// SELECT ... FROM customers LIMIT 10, 20
// SELECT ... FROM orders WHERE customer_id IN (.....)

and/or, could there be a way to trigger a "query-join" against an existing array of entities? for example

$query = $em->createQuery('SELECT c FROM Customers c'); // single query to fetch customers
$customers = $query->getResult(); // array of Customer objects
$em->join($customers, 'orders'); // fetch and hydrate the 'orders' association on each Customer using a single query

Perhaps at some point in the future Doctrine/DBAL could even make use of asynchronous queries (i.e. mysqlnd supports this) to allow these query-joins to run in parallel and the result would be more efficient paginated resultsets.

Thoughts/feedback?



 Comments   
Comment by Benjamin Eberlei [ 30/Sep/10 ]

There is another approach for this using several subqueries to build an IN clause, the Paginator extension supports this: http://github.com/beberlei/DoctrineExtensions

I rather go the extension approach than changing the DQL for this feature.

Comment by Benjamin Eberlei [ 30/Sep/10 ]

I just saw your second example, that is rather cool though and gets +1 from me.

I had the same idea for "not initialized proxies", i.e.

$em->getUnitOfWork()->initializeProxies('Customer');
Comment by Marc Hodgins [ 29/Dec/10 ]

Second example is a duplicate of DDC-734

Comment by Guilherme Blanco [ 30/Jul/13 ]

Fixed based on this related issue: http://www.doctrine-project.org/jira/browse/DDC-734





[DDC-745] DateTime with SQLite Created: 12/Aug/10  Updated: 13/Aug/10  Resolved: 12/Aug/10

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA4
Fix Version/s: 2.x
Security Level: All

Type: Bug Priority: Minor
Reporter: Rui Lima Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Windows 7 - Portuguese Regional Settings
XAMPP
SQLite database



 Description   

I was using 2.0.0-Beta3 no problems found.
Then upgraded to Beta4 and the following:

Fatal error: Uncaught exception 'Doctrine\DBAL\Types\ConversionException' with message 'Could not convert database value "2010-08-07 00:00:00.000" to Doctrine Type datetime' in

I guess it's an ORM's problem.

I've traced to:
call stack:
Doctrine\DBAL\Types\DateTimeType->convertToPHPValue()
Doctrine\ORM\Persisters\BasicEntityPersister->_processSQLResult()
Doctrine\ORM\Persisters\BasicEntityPersister->_createEntity()
Doctrine\ORM\Persisters\BasicEntityPersister->load()
Doctrine\ORM\Persisters\BasicEntityPersister->findOneBy()

in Doctrine\DBAL\Types\DateTimeType->convertToPHPValue() i receive the values:
$value = "2010-08-07 00:00:00.000"
$platform->getDateTimeFormatString() = "Y-m-d H:i:s"

I'm new to Doctrine, maybe is my problem but it was working before i've upgraded everything.
I'll also try to find out what is going on, but just to let you guys know.

=================0
System:
Windows 7 - Portuguese Regional Settings
XAMPP
SQLite database



 Comments   
Comment by Rui Lima [ 12/Aug/10 ]

I took a closer look to my problem.
I used and external tool to update the field, and instead of '2010-08-07 00:00:00' the tool inserted '2010-08-07 00:00:00.000'

So, there is no problem.
Thanks and sorry.

Comment by Benjamin Eberlei [ 12/Aug/10 ]

Does sqlite allow microseconds by default?

Comment by Rui Lima [ 13/Aug/10 ]

I don't quite understand you question.

both of the following works:
update tb_user set registerdate='2010-08-07 00:00:00'
update tb_user set registerdate='2010-08-07 00:00:00.000'

And here: http://www.sqlite.org/lang_datefunc.html
we can see that YYYY-MM-DDTHH:MM:SS.SSS is one of the supported formats.

On other hand when i execute:
select DATETIME('NOW') -//>2010-08-13 09:14:21

So i guess the default is with no miliseconds.

Could we make possible to specify the datetime format in the annotation reference?





[DDC-222] Create unit tests for CLI components Created: 22/Dec/09  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA3
Fix Version/s: 2.x
Security Level: All

Type: Task Priority: Critical
Reporter: Roman S. Borschel Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-359 Specified, but empty CLI Options --op... Resolved

 Comments   
Comment by Roman S. Borschel [ 19/May/10 ]

Whats the status here? Do we have any?

Comment by Guilherme Blanco [ 19/May/10 ]

Since we moved to Symfony Console I don't think this is needed anymore.
The purpose of this ticket was actually to test our own CLI support, which was dropped.

I'm closing the ticket due to this. Reopen if you have any other comment.

Comment by Benjamin Eberlei [ 20/May/10 ]

I think we do need some basic functional tests of our Commands, they have been subject to many bugs in the past becaues they are not tested.

Comment by Benjamin Eberlei [ 19/Jun/10 ]

Fixed another fatal error in the command due to missing namespace dependency. We need tests for all the commands, there have been dozens of issues on these things so far.

This commit shows a simple approach on how testing is easily possible for symfony commands:

http://github.com/doctrine/doctrine2/commit/51e6681934a7cf4448b85c5670c04045f66c6056

Comment by Roman S. Borschel [ 26/Aug/10 ]

Can we expect some more tests for beta4 or is it unlikely that you find the time? Should we move this further back or does someone else want to step in?

Comment by Guilherme Blanco [ 16/Apr/14 ]

This is not valid anymore as we use Symfony CLI component





Generated at Fri Aug 29 08:03:38 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.