-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to create where - group by queries without querybuilder? #501
Comments
If I understand your query correctly, you are doing multiple filtering in findBy() and one of them is an aggregation and others not. Yes, it is currently buggy. Could you please try out this PR which could fix it? It does extensive rewrite of the query so I need to more verification it doesn't break anything else. |
No no, I am probably doing something which is outside of ORM scope. I have a table with many records and repository-mapper-entity for individual access to these records. But I also need classic
but even if I use queryBuilder for building that query with usage of entity definition, I have no access to COUNT(*) column because it cannot be described in entity. Probably it is necessary to build view for every group-by select and build individual repository-mapper-entity set for every view or use only DBAL layer (no ORM)... Am I right? Or is there any theoretical construct how to create sub-summary over entities without iterating over all records? |
You may override the DbalMapper's builder method to select these data for your entity. But ORM is definitely (edit: NOT) designed for this type of selects. You can also utilize an actual column and update its content with triggers. |
Closing as I don't see potential to support selecting a grouped result explicitly. |
My solution:
The only pity is that I need to identify such aggregation column to same name as property in aggregation entity. So I used "aggregatedValue" and it is constant name in my DbalCollection descendant and in aggregation entities. Much better solution can be some virtual property in entity for storing aggregation values and detect its name in my DbalCollection descendant. The result is that all rows in aggregated queries are still entities and works perfectly in grids, tables etc. You wrote "But ORM is definitely designed for this type of selects.". Hmm, there is a way how to use it but a lot of programming - not so stright forward. |
Oh, sorry, the sentence misses the most important word - NOT. :D |
That makes sense :-) OK, nevermind, solution found, it is only 10 minutes more work in every aggregation. Thanks for great ORM anyway. |
If I use CountAggregateFunction inside findBy(), every condition from findBy went to HAVING clause. But I want to use all of these in WHERE clause, than perform aggregation and (possibly) something makes in HAVING or leave HAVING empty.
How can I distinguish, which conditions go to WHERE and which to HAVING?
The text was updated successfully, but these errors were encountered: