Skip to content
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

Allow DQL functions to specify return type #7941

Merged
merged 1 commit into from
Dec 12, 2019
Merged

Allow DQL functions to specify return type #7941

merged 1 commit into from
Dec 12, 2019

Conversation

Grafikart
Copy link
Contributor

Some functions have a predefined type and could be resolved correctly by the SQLWalker. I don't want to change things too much but it could be possible to do the same thing for other functions like SUM for instance that would be resolved to float.

This is the follow up of the #7641 PR (I won't delete it this time sorry for the inconvenience)

Copy link
Member

@ostrolucky ostrolucky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copying my review here

It's a nice, simple patch solving the problem, however I'm not sure we should bite the bullet with floats. COUNT() and LENGTH() as integer types are fine, but casting to float in PHP will mean losing accuracy. It's also quite strange to make eg. ABS(1) return 1.0. Also, this a BC break and as such should be documented.

If more dpeople could share their opinion about what I writtent, that would be nice too

@Grafikart
Copy link
Contributor Author

@ostrolucky If you want I could postpone the change on ABS() so the new feature can be merged without BC (knowing we would have to change it in the future).

@ostrolucky
Copy link
Member

Before doing that, let's see what other doctrine maintainers think. WDYT @doctrine/doctrinecore ?

@SenseException
Copy link
Member

master is the next major release. Isn't this a fitting time to introduce a BC break?

Copy link
Member

@lcobucci lcobucci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changeset is quite nice indeed. The title is a bit misleading since the previous behaviour was working as intended, I'd consider this as an improvement of the API.

The usage of floats for SUM(), AVG(), and ABS() might indeed cause some trouble with precision (which is why we don't do casts for decimal columns). I'd say we should leave them as string for now and have this targeting v2.8.0.

@lcobucci lcobucci changed the base branch from master to 2.8.x December 12, 2019 10:56
@lcobucci lcobucci changed the title fix: functions being casted as string Allow DQL functions to specify return type Dec 12, 2019
@lcobucci lcobucci added this to the 2.8.0 milestone Dec 12, 2019
Comment on lines +41 to +53
$query = $this->_em->createQuery(
'SELECT
COUNT(product.id) as count,
SUM(product.price) as sales,
AVG(product.price) as average
FROM ' . GH7941Product::class . ' product'
);

$result = $query->getSingleResult();

self::assertSame(6, $result['count']);
self::assertSame('325', $result['sales']);
self::assertRegExp('/^54\.16+7$/', $result['average']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Grafikart this is what I meant with a more functional approach 😄

The main advantage is that we only rely on the public API here, which makes it easier to detect BC-breaks.

By using self::assertSame() we check that both value and type match expected value and self::assertRegExp() only accepts strings.

Copy link
Member

@lcobucci lcobucci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good to go IMHO, it would be nice to have another pair of eyes here.

It might be good to document a minor behaviour change regarding the return type of COUNT() and LENGTH() - there's no need for casting it to integer anymore. What do you think @doctrine/team-orm-documentation?

@lcobucci lcobucci merged commit 4aa0986 into doctrine:2.8.x Dec 12, 2019
@lcobucci lcobucci self-assigned this Dec 12, 2019
@lcobucci
Copy link
Member

@Grafikart thanks! 🚢

@SenseException
Copy link
Member

In some cases functions like COUNT are already documented with an integer return type: https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/dql-doctrine-query-language.html#pure-and-mixed-results
This is now some kind of self-fulfilling prophecy (even though the change is for 2.8).

@VincentLanglet
Copy link
Contributor

@Grafikart When I use COUNT with getSingleResult, I now get

[ 0 => 42 ]

But if I use getSingleScalarResult I get '42'.

Shouldn't the result be consistent ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants