|
Increasing the severity and adding a fix version since this MUST be fixed before next release.
|
|
I find this to be of rather minor importance. You're talking of compatibility breaks, but thats only the case if we intend to start being very nitpicky about the naming in the future. We are currently not, and we wont be, so not much risk of later breakage.
We have a rule of thumb already: Acronyms up to 4 characters all uppercase, otherwise normal camelcase.
Now, it is often a matter of taste what is an acronym and what not and also not all acronyms have a clear casing, prime example mysql.
Being too nit-picky here is just a pain in the ass and we won't reach a common consensus anyway.
|
|
Oh and we better dont start arguing about whats better to read because there is no chance of agreement. If you ask me I find SQLException better than SqlException. So here we go. Lets better not run down this path.
|
|
No need to get upset, I'm only trying to help.
I just thought that consistency is usually a good idea, either way.
I have to disagree in that an acronym is an acronym, it's not a matter of taste, the letters either stand for something, or they don't.
As for "mysql", only the SQL part is an acronym. So, MySQL or MySql.
Close if you disagree.
|
|
I'm not upset. What made you think so? Maybe I should introduce a  every now and then.
There's just no point in arguing about readability.
Like I said, we do have a naming standard even if its not adhered everywhere. The standard is also not something we've made up ourselves because we try to avoid that. When we introduced namespaces, we talked about adopting either the Java or .NET naming standards. We opted for the .NET standards. And there its recommended to write acronyms with up to 4 characters all uppercase.
I dont think there are too many violations of that in the code, probably Cli => CLI and some others but most of it looks ok to me.
UPDATE: Maybe we can gather a list here in this ticket of violations? Cli => CLI would be one. MySql => MySQL another. "Id" is rather an abbreviation of Identifier and not an acronym, to me at least.
|
|
It's not a case of getting anyone upset...
But we should fix it and keep consistency of our codebase.
@romanb We should all talk and reach a common sense.
That's our last chance (last alpha) to get this consistency in.
|
|
@Guilherme: We do have a naming standard since a year. You want to change the standard now?
|
|
@Roman,
Just a feeling I got.
This issue was more about consistency (indicated in the title) than moving to proper-case naming.
I think it might be up to 3 characters in .NET, HtmlElement, System.Linq, etc. Anyway, not important. 
I agree that Id. is an abbreviation.
There are some more violations. If you decide you want to change them, let me know and I'll compile a list.
|
|
@Glen: Yes, a list would be great. I find it hard to be 100% consistent sometimes though because my taste conflicts with the rule. For example, I would prefer "Id" over "ID", especially since it comes directly after ORM "Doctrine\ORM\ID\..." would be a bit too much. But I would not like "Orm" or "Dbal" either. But I think in most cases we can clearly fix the inconsistency. Like CLI or MySQL or MSSQL (or should it be MsSQL?).
Thanks for your help!
We should probably create updated coding standards for Doctrine 2 also, since they differ quite some from Doctrine 1 due to the introduction of namespaces and such. I'll create a ticket for that.
|
|
I'll do the list for you by tomorrow at the latest, just running out of time ATM.
Id is correct, as mentioned above, so that would be fine. MsSQL is correct (Ms = Microsoft = abbreviation).
|
|
Found some time ...
Doctrine\Common\Cache\ApcCache -> APCCache
Doctrine\Common\Cli -> CLI
Doctrine\Common\Cli\Printers\AnsiColorPrinter -> ANSIColorPrinter
Doctrine\Common\Cli\CliController -> CLIController
Doctrine\Common\Cli\CliException -> CLIException
Doctrine\DBAL\Driver\PDOMsSql -> PDOMsSQL
Doctrine\DBAL\Driver\PDOMySql -> PDOMySQL
Doctrine\DBAL\Driver\PDOPgSql -> PDOPgSQL
Doctrine\DBAL\Driver\PDOSqlite -> PDOSQLite
Doctrine\DBAL\Logging\EchoSqlLogger -> EchoSQLLogger
Doctrine\DBAL\Logging\SqlLogger -> SQLLogger
Doctrine\DBAL\Platforms\MsSqlPlatform -> MsSQLPlatform
Doctrine\DBAL\Platforms\MySqlPlatform -> MySQLPlatform
Doctrine\DBAL\Platforms\PostgreSqlPlatform -> PostgreSQLPlatform
Doctrine\DBAL\Platforms\SqlitePlatform -> SQLitePlatform
Doctrine\DBAL\Schema\Visitor\CreateSchemaSqlCollector -> CreateSchemaSQLCollector
Doctrine\DBAL\Schema\Visitor\DropSchemaSqlCollector -> DropSchemaSQLCollector
Doctrine\DBAL\Schema\MsSqlSchemaManager -> MsSQLSchemaManager
Doctrine\DBAL\Schema\MySqlSchemaManager -> MySQLSchemaManager
Doctrine\DBAL\Schema\PostgreSqlSchemaManager -> PostgreSQLSchemaManager
Doctrine\DBAL\Schema\SqliteSchemaManager -> SQLiteSchemaManager
Doctrine\DBAL\Tools\Cli -> CLI
Doctrine\DBAL\Tools\Cli\Tasks\RunSqlTask -> RunSQLTask
Doctrine\ORM\Mapping\Driver\PhpDriver -> PHPDriver
Doctrine\ORM\Mapping\Driver\XmlDriver -> XMLDriver
Doctrine\ORM\Mapping\Driver\YamlDriver -> YAMLDriver
Doctrine\ORM\Query\Exec\AbstractSqlExecutor -> AbstractSQLExecutor
(Should Doctrine\ORM\Query\Expr\Andx and Orx be AndX and OrX?)
Doctrine\ORM\Query\SqlWalker -> SQLWalker
Doctrine\ORM\Tools\Cli -> CLI
Doctrine\ORM\Tools\Cli\Tasks\RunDqlTask -> RunDQLTask
Doctrine\ORM\Tools\Export\Driver\PhpExporter -> PHPExporter
Doctrine\ORM\Tools\Export\Driver\XmlExporter -> XMLExporter
Doctrine\ORM\Tools\Export\Driver\YamlExporter -> YAMLExporter
... I think that's it. More than you expected? I did say: "There is more proper-casing than upper-casing."
|
|
No, not more than I expected. It's mostly SQL and CLI basically. Thanks for the list!
We should try to go through that list before beta.
|
|
Methods should be adjusted accordingly also (even though they're case insensitive). I already started with that. More to come.
|
|
Most of the Cli => CLI changes seem to be complete now.
|
|
Pushing the rest of the name changes towards beta2.
|
|
More renamings have been done but still more to do. Pushing remaining work to beta3.
|
|
Final name changes should be done prior to going into RC1.
|
|
there is much to be done yet, however most of it is also public API class names and might cause quite some BC breaks (i.e. DBAL Platforms and Schema Manager, Mapping Driver Names). I am not sure how to proceed here.
|
|
Since PHP is mostly case-insensitive on class and method names it shouldn't be much of an issue.
|
|
Did this get fixed with the correction of your data?
|
|
No it did not. This issue is completely unrelated to the other one.
For this, I have manually implemented workarounds, fetching the associations using DQL queries. Lazy loading in the inheritance scenario above still would not work.
|
|
So A is an entity in a hierachy A -> B, and "someRelationship" is a field on A or on B  towards an Entity C that is in an inheritance hierachy or not?
Could you post parts of the mappings (entity docblock and the relationship)?
|
|
Hey, thanks for taking care of this.
I attached the entities involved in the szenario to this issue.
I had problems lazy loading entities through the following associations:
Run.invoiceCreatorResult
Run.commissionNoteCreatorResult
Run.consumerInvoiceExporterResult
as well as
InvoiceCreatorResult.dataVersion
CommissionNoteCreatorResult.dataVersion
ConsumerInvoiceExporterResult.dataVersion
In this scenario, InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult all inherit from Result, which in turn inherits from a mapped superclass DataObject. Run and DataVersion inherit from DataObject directly.
The associations where lazy loading does not work are associations both to and from the entity classes InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult.
|
Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".
Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.
Just a short Q on understanding: Why is $a a proxy of A if you select it explicitly?
|
|
This a working test-case with a model that i believe resembles yours exactly.
I also put your models into another test and ran schema validation on them, which works out without problems.
From the workflow with proxies, maybe DDC-1452 might be related to your issue?
|
|
Regarding the proxy question, I just ment the query to be an example to further illustrate the type of $a. It was redundant and unnecessary though and probably misleading. Sorry for that. I did not select anything in the actual scenario. $a is merely some object of type A. No queries are involved.
|
|
Have you been able to make the tests fail with the original data provided?
If not, I could set up a test case and post it.
|
|
No i only checked the validity of mappings with the original data. If you could setup a testcase that would be really great.
|
|
I will set up a test case and upload it. I'll see if I can do it one of the next evenings.
|
|
I tried again, also extended DDC-1390, but it was impossible for me to reproduce this. I ran this against master, 2.1.x and 2.1.1 specifically.
|
|
Sorry, I got swamped with work. Now I am working on this dedicatedly, testing against the latest release. Will let you know once I have a testcase.
|
|
Good to hear, thanks for the persistent work on this.
|
|
If this is to be included in 2.0 it needs to happen for RC1. However, it is not clear yet whether it will be done in time.
|
|
How would you solve this Roman? I thought of adding a query hint so that the postLoad inside unit of work is not triggered and gathering all the entities that have a post load event in an array inside the object hydrator, then iterating it after taking the snapshots of all collections inside hydrateAll
|
|
@Benjamin: Not sure what you would use the query hint for but in general that is the approach I had in mind, yes. You can't get around iterating over the entities after the actual hydration.
|
|
The query hint would do something like:
if (isset($class->lifecycleCallbacks[Events::postLoad]) && !isset($hints['hydrationPostLoad'])) {
$class->invokeLifecycleCallbacks(Events::postLoad, $entity);
}
if ($this->evm->hasListeners(Events::postLoad) && !isset($hints['hydrationPostLoad'])) {
$this->evm->dispatchEvent(Events::postLoad, new LifecycleEventArgs($entity, $this->em));
}
another way would be to move that code out of UoW::createEntity completly and have the persisters call it when they use that method.
|
|
Leaving that code in UoW does not make sense to me, if it is moved, it needs to be moved completely. Why do you think the persisters should do it? Initially I thought collecting the affected entities during hydration and then when hydration is done iterating over them and triggering the postLoad events.
|
|
Yes but postLoad has to be triggered for non Hydrated entities (i.e. Persister) also
|
|
Moved back
|
|
Hi Gyus, I need access to associations in postLoad or similar event, and my idea is to dispatch new event after full initialisation of object, what do You think about it? If I can help please let me know It's important for me.
|
|
Now in my PostLoad access to associations is work fine. Why this issue is still in Unresolved status?
|
|
What do you (Roman and Benjamin) think about adding postHydrate event which would be called within ObjectHydrator::hydrateAllData() on every entity collected during hydration? I could prepare a patch for this. I personally think this would be better than adding a hint that changes behaviour of postLoad event.
|
|
Hi
Could you please attach your entities or a failing test case ?
Cheers
|
|
sure
LineRelated.php :
class LineRelated
{
/**
* @ORM\Id
* @ORM\Column(type="integer")
* @ORM\GeneratedValue(strategy="AUTO")
*/
protected $id;
/**
* @ORM\ManyToOne(targetEntity="Line", inversedBy="line_related")
* @ORM\JoinColumn(name="line_id", referencedColumnName="id",nullable=false)
*/
protected $line;
/**
* @ORM\Column(name="line_id_related", type="integer")
*/
protected $line_related;
/**
* @ORM\Column(type="smallint",nullable=false)
*/
protected $count = 0;
###### get/set etc....... #######
Line.php
class Line
{
/**
* @ORM\Id
* @ORM\Column(type="integer")
* @ORM\GeneratedValue(strategy="AUTO")
*/
protected $id;
########## blablabla #############
my action:
public function right_line_relatedAction($line = null, $title='相关线路')
{
$lines = $l->getByUser($user, array());
$related = $this->getDoctrine()->getRepository('MyWebBundle:LineRelated')->findBy(array('line' => $lines), array('count' => 'DESC'), 20);
return $related;
}
|
|
Hi,
How did you get this query string ?
Repository#findBy does not quote the values, It uses PDO:bindParam.
so the expected query string should be someting like :
WHERE t0.line_id IN (?, ? ,?)
I tried to reproduce but in my tests the generated Query binds the parameters as "PDO::PARAM_INT".
I have added a test case.
Could you please can try to change it and make fails.
Cheers
|
|
reproduced :
SELECT t0.id AS id1, t0.line_id_related AS line_id_related2, t0.count AS count3, t0.line_id AS line_id4 FROM line_related t0 WHERE t0.line_id IN ('6059', 4851, '6068', 126352, '6060', '1000000') ORDER BY t0.count DESC LIMIT 20
Parameters: [['6059', 4851, '6068', 126352, '6060', '1000000']]
[Hide runnable query]
Time: 234.53 ms [ Explain query ]
let me have a look on what's going on
|
|
interesting. I've dump(using ladybug_dump) the $lines,and I found out that when the element is a Proxies Object(Object(Proxies_GC_\My\WebBundle\Entity\Line)),then the id of that Object will be with quoted,when the elememt is an Real Entity,then It will be without quote.
for example,in my last comment, the parameters is [['6059', 4851, '6068', 126352, '6060', '1000000']]
the result of dumping $lines is :
array(6)
[0]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[1]: object(Zuo\WebBundle\Entity\Line)
[2]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[3]: object(Zuo\WebBundle\Entity\Line)
[4]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[5]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
tell me if you need more information. thanks
|
|
This may be because
in proxies ( https://github.com/doctrine/doctrine2/blob/42e83a2716d19eada4f1cd49ece77d5f5229a239/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L383 ) is not necessarily composed by integers. This could be fixed with DCOM-96. I'll add the tests to my development branch and will ping you back tomorrow
|
|
thanks
|
|
I see what is going on here... But this should not be a problem anyway, since they're bound anyway as "PDO::PARAM_INT", as Fabio B. Silva told you.
That's only a problem with the logger showing them as string. PDO will handle the conversion before the value hits the DB as far as I know.
|
|
I can understand your point,but what I don't really get is that the execute time of sql is very long,that explained the quote should be in the sql,not like what you said,that's only a problem with the logger.
|
|
scourgen can you profile the difference directly in CLI? What about checking the bound parameter type? Are those values bound as INTs in your case?
|
|
@ocramius I wish I could, but I was using doctrine2 with symfony2,So It looks like It will takes some time to simulating all environment and settings that could allow me to reproduced the problem.
but anyway,I will have a try and tell you what happen when I found something.
|
|
scourgen ok, awaiting your reply then
|
|
I've spent some time on playing with native doctrine2. It took me awhile to setup everything. but I just don't get that how to retrive data with its Proxy ojbect(for example Proxies_CG_\My\WebBundle\Entity\Line).
I mean the result of
$this->_em->getRepository("something")->findxxx()
always return an array of real object. I can't reproduced the situation(#comment-19186) that happens on symfony2+doctrine2.
anyway,I can make sure the problem is real exist,Because the execute time of that slow sql from the tool bar of symfony2 is same as I executed it at mysql cli. If the sql shows up on log with quote but running at mysql without quote,the execute time won't be same(actually It will be much more faster,in my case,20x times,from 2xxms to 10ms).
|
|
scourgen you can use
$em->getReference($className, $identifier)
(identifier being a key=>value array) to force proxies.
Give it a try
|
|
looks like I reproduced it.
public function testIssue()
{
$no_used= $this->_em->getRepository(__NAMESPACE__. '\DDC2214Line')->findOneById(1);
$lines=array(
$this->_em->getReference(__NAMESPACE__. '\DDC2214Line',1),
$this->_em->getReference(__NAMESPACE__. '\DDC2214Line','2'),
$this->_em->getReference(__NAMESPACE__. '\DDC2214Line',3),
);
$logger = $this->_em->getConnection()->getConfiguration()->getSQLLogger();
$ids = array_map(function($r){
return $r->id;
}, $this->relatedList);
$related = $this->_em->createQuery('select lr from '.__NAMESPACE__ . '\DDC2214LineRelated lr where lr.id in (:ids)')->setParameter('ids',$lines)->getResult();
$query = end($logger->queries);
$this->assertCount(3, $related);
$this->assertEquals($ids, $query['params'][0]);
$this->assertEquals(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY, $query['types'][0]);
}
}
I use MySql Query log to see what's really happen in database(http://dev.mysql.com/doc/refman/5.5/en/query-log.html)
this is the log from table mysql.general_log
2013-01-08 12:23:44 [root] @ localhost [127.0.0.1] 59 0 Connect root@localhost on doctrine_tests
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query CREATE TABLE DDC2214Line (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query CREATE TABLE DDC2214LineRelated (id INT AUTO_INCREMENT NOT NULL, line_id INT NOT NULL, count SMALLINT NOT NULL, line_id_related INT NOT NULL, INDEX IDX_D31307994D7B7542 (line_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query ALTER TABLE DDC2214LineRelated ADD CONSTRAINT FK_D31307994D7B7542 FOREIGN KEY (line_id) REFERENCES DDC2214Line (id)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query START TRANSACTION
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (1, 1, 1)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (2, 2, 2)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (3, 3, 3)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query COMMIT
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query SELECT t0.id AS id1 FROM DDC2214Line t0 WHERE t0.id = 1 LIMIT 1
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Query SELECT d0_.id AS id0, d0_.count AS count1, d0_.line_id_related AS line_id_related2, d0_.line_id AS line_id3 FROM DDC2214LineRelated d0_ WHERE d0_.id IN (1, '2', 3)
2013-01-08 12:23:44 root[root] @ localhost [127.0.0.1] 59 0 Quit
you can see,in database level,the second parameter of last query but two has quote ( (1, '2', 3) )
|
|
A related Github Pull-Request [GH-247] was opened
https://github.com/doctrine/common/pull/247
|
|
A related Github Pull-Request [GH-247] was closed
https://github.com/doctrine/common/pull/247
|
|
Suppose I have the following entities:
/**
* @ORM\Entity
* @ORM\Table(name="driver")
*/
class Driver
{
/**
* @ORM\Id
* @ORM\Column(type="integer")
* @ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* @ORM\Column(type="string", length=255);
*/
private $name;
/**
* @ORM\OneToMany(targetEntity="DriverRide", mappedBy="driver")
*/
private $driverRides;
}
/**
* @ORM\Entity
* @ORM\Table(name="driver_ride")
*/
class DriverRide
{
/**
* @ORM\Id
* @ORM\ManyToOne(targetEntity="Driver", inversedBy="driverRides")
* @ORM\JoinColumn(name="driver_id", referencedColumnName="id")
*/
private $driver;
/**
* @ORM\Id
* @ORM\ManyToOne(targetEntity="Car", inversedBy="carRides")
* @ORM\JoinColumn(name="car", referencedColumnName="brand")
*/
private $car;
}
/**
* @ORM\Entity
* @ORM\Table(name="car")
*/
class Car
{
/**
* @ORM\Id
* @ORM\Column(type="string", length=25)
* @ORM\GeneratedValue(strategy="NONE")
*/
private $brand;
/**
* @ORM\Column(type="string", length=255);
*/
private $model;
/**
* @ORM\OneToMany(targetEntity="DriverRide", mappedBy="car")
*/
private $carRides;
}
And want to query for Cars that a Driver drove in:
$qb = $em->createQueryBuilder();
$qb->select('d, dr, c')
->from('Driver', 'd')
->leftJoin('d.driverRides', 'dr')
->leftJoin('dr.car', 'c')
->where('d.id = ?1') /* some Driver id */
->getQuery()->getArrayResult();
Expected results:
I expect to get an array with an index 'driverRides' with an array of Cars (depending on the data of course).
Actual result:
Just an array with Driver data.
When I started doing some testing I found out I get a different result when I add a third column to the DriverRide table that isn't part of the composite primary key.
Now I did get a 'driverRides' array, but with just a single row and not three as I expected to get in my case.
When I removed the composite key and used an auto-generated id-column, everything worked as expected.
Some test data you might want to use:
INSERT INTO `car` (`brand`, `model`) VALUES
('BMW', '7 Series'),
('Crysler', '300'),
('Mercedes', 'C-Class'),
('Volvo', 'XC90');
INSERT INTO `driver` (`id`, `name`) VALUES
(1, 'John Doe'),
(2, 'Foo Bar');
INSERT INTO `driver_ride` (`driver_id`, `car`) VALUES
(1, 'Crysler'),
(1, 'Mercedes'),
(1, 'Volvo'),
(2, 'BMW');
|
|
Rescheduling for beta3.
|
|
Pushing back to beta4.
|
|
Moved to 2.1 due to lack of time for any larger new features for 2.0.
|
|
implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1
http://github.com/doctrine/doctrine2/tree/OverridePersisters
|
|
Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature
|
|
This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on.
So I cannot merge this, because the API will probably break big time.
|
|
Does that mean we will not see this feature before 2.2?
|
|
Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks.
I will update the target version accordingly.
Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it.
|
|
Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this
|
|
I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage?
|
|
@Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query.
We missed it, yes. I may reschedule for 2.3
|
|
Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager.
|
|
Any change seeing this soon? I really need this for a security feature.
What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick.
I don't need any fancy stuff, just a way to limit the fields in the SELECT list.
Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private!
Got any other idea?
|
|
Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance.
|
|
Can you also test this with doctrine >= 2.3? The pagination code changed quite a lot.
|
|
Looks like no change
composer.json:
"doctrine/orm": "2.3.*",
–
php composer.phar update
Loading composer repositories with package information
Updating dependencies
- Installing doctrine/common (2.3.0)
Loading from cache
- Installing doctrine/dbal (2.3.2)
Loading from cache
then cleared cache but result is same
Here's the code
$query = $this->getDoctrine()->getEntityManager()->getRepository('MyBundle:Invoice')
->createQueryBuilder('q')
->select('q', 'SUM(q.amount) AS amount')
->groupBy('q.customer')
;
95 Connect root@localhost on **
95 Query SELECT DISTINCT id0 FROM (SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9 FROM Invoice i0_ GROUP BY i0_.customer_id) dctrn_result LIMIT 30 OFFSET 0
95 Query SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ WHERE i0_.id IN ('2') GROUP BY i0_.customer_id
95 Query SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ GROUP BY i0_.customer_id
130210 16:08:25 95 Quit
But I understand why that happens, it's due to group by and pagination nature.
The first query returns only one row with id "2", second query should be actually "..WHERE i0_.id IN ('2', '3', '4')"
If I do
$pager = new Pagerfanta(new DoctrineORMAdapter($query, false));
I get this sql
SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ LIMIT 30 OFFSET 0
I think it should be noted somewhere that if you do groupBy you should set fetchJoin to false?
|
|
Updating to Documentation issue.
|
CommissionNoteCreatorResult.php
