http://coldfusion.com logo
Join Slack
Powered by
Not sure if bug, but got error in project because ...
# lucee
r
Not sure if bug, but got error in project because of that - query by query with aggregates on empty Query gives 1 empty record
image.png
w
i suspect it's merely returning NULL, no?
what is your expectation, that it should return an empty resultset or return 0?
r
honestly, I don't know 🙂 there should be convention of some kind what to be returned, I feel 0 is not good either. In project I fixed a bug as previous developer expected there to be "RecordCount eq 0"
maybe the behavor changed over the years ?
w
NULL + 12 + 32 = NULL
so an aggregate on those will return NULL
easy enough to protect against with ISNULL/IFNULL but as i said it depends on what your expectation is. i'd be more inclined to check the rowcount of the first query before bothering with the second
but i have no context
z
which version?
@bdw429s has done a lot of correctness improvements, to match db behaviour
r
5.3.9.166
@websolete yes, I prob agree, it should be NULL that translates to empty string in 2nd query
w
fwiw, this DOES match db behavior
🗿 1
✅ 1
z
what does trycf do with 5.3.10.120?
r
checked - same
Well well well, ACF2021 returns empty dataset!
image.png
So now I know - the bug I fixed was there since ACF migration... on ACF RecordCount eq 0, but in Lucee it's 1
z
a
IMO one row with null (which in CFML land translates to an empty string in the query object) is correct. MySQL (which I presume is sticking to standards) does this when queried directly Lucee querying MySQL does this Lucee QoQing does this CF sounds wrong to me. eg from MySQL:
Copy code
mysql> SELECT SUM(int_col) as sum_int_col FROM t1 WHERE never_null_col IS NULL;
+-------------+
| sum_int_col |
+-------------+
|        NULL |
+-------------+
1 row in set (0.00 sec)

mysql>
b
@rodyon Every major RDBMS returns a single row containing null (unless you use isnull) when you apply an aggregate on an empty resultset and DON'T use 
group by
. This includes MSSQL, MySQL, PostreSQL, and Oracle.
Lucee was modifed to match this industry standard a couple years ago. (released in 5.3.8)
The ticket for Adobe to fix themselves is here: https://tracker.adobe.com/#/view/CF-4211230
⭐ 1
r
I agree, it consistent with querying database, but not consistent with ACF 🙂 it depends where choose to get 'standard behavior'
b
When I consider Adobe wrong, I prefer to fix Lucee and put in a ticket for Adobe to fix themselves as well 🙂
Adobe has had my ticket marked "To fix" since early 2021 😕
But everyone got GraphQL instead 😆
😜 2
z
evangelists have to evanglize, sorry @Mark Takata (Adobe)
b
I actually have about 4 or 5 tickets in for Adobe for various things I've fixed in Lucee QoQ that Adobe still has wrong
a
since early 2021
OK well give it until 2031 or so before getting impatient please, @bdw429s
b
lol
a
I'm hoping they focus more on 
<cfchatgpt>
before then. Priorities.
✅ 1
🙏 1
b
But basically Lucee QoQ has been "ahead" of Adobe QoQ for quite a while. Lucee's QoQ performance kicks Adobe's butt now (well, when Lucee 6 comes out...) https://www.codersrevolution.com/blog/improving-lucees-qoq-support-again-now-200-faster
a
But basically Lucee QoQ has been "ahead" of Adobe QoQ for quite a while.
That is damning with faint praise a bit. ;-) But that also should not take anything away from yer excellent efforts, Mister Wood.
More helpfully: I have just voted for all those CF tickets. And I invite other readers here to do the same.
✅ 1
m
@Bagish Mishra this is the type of ticket you and I discussed the other evening. Long standing, language behavioral, quality of life/standards matching which is sitting idle. cc: @Charvi
⭐ 3
👍 1
z
💥 3
2 Views
Open in Slack
PreviousNext
Powered by