Any reason why this ain't a bug in CF: https://trycf.com/gist/2a0778dd736b7d7c411ab8685c836bb6/acf2021?theme=monokai

week = queryNew("id,en,mi", "integer,varchar,varchar", [
	[1,"Monday","Rāhina"],
	[2,"Tuesday","Rātū"],
	[3,"Wednesday","Rāapa"],
	[4,"Thursday","Rāpare"],
	[5,"Friday","Rāmere"],
	[6,"Saturday","Rāhoroi"],
	[7,"Sunday","Rātapu"]
])

week.some((row, i) => {
    writeOutput("In loop #week.currentRow# [#i#]<br>")
    
    //return i == 5 // this works fine on CF
    return week.currentRow == 3 // this does not: it's always 1
})

currentRow

does not get incremented as the query is iterated over; it's always

1

. Lucee behaves how I'd expect.

That does very much look like a bug. The docs on Adobe's site (and CFDocs) clearly state that the second argument to the closure (

i

in your example) should return the

currentRow

value. I will say that Adobe's examples, while correct, are confusing for a newbie as they both define the closure outside the

some

call and use the new arrow syntax. While both things are completely valid and might be good syntactic "sugar", they make it hard for someone just learning about

querySome()

or

.some()

for the first time to follow.

Adobe docs are vague and not very helpful??! I won't hear of it, Carl.

I apologize if this doesnt add anything to this conversation, but I've been looking at this code/question for a bit and I'm confused. Wouldn't

week.currentRow

be expected to return 1 when not being looped over? Is your code trying to set the default `currentRow`for

week

via your

some()

function? Apologies again if I'm completely misunderstanding the issue.

The

.some()

function does indeed return a boolean. However, inside the closure (the first argument passed inside

.some()

) you should have access to the

row

,

currentRow

, and the entire

query

. This is in keeping with how CF handles all of these higher-order functions related to queries (and similar to higher-order functions for other data types).

gotcha, thank you for the clarification and additional info on

some()

. On line 18 of your example, outside of your

some()

function, you have

writeOutput("After loop #week.currentRow#<br>")

. Wouldn't this just be 1 as long as there was even a single row in your query (otherwise it'd be 0)? Is the problem that this code (line 18) is returning 1 and you were expecting 3?

Ah, well see that's a relic of what I was originally testing before I noticed the CF bug. Also why I was using

some

instead of

each

: I wanted to early-exit the iteration process, and examine where the row pointer ended up being. I was hoping CFML would maintain the currentRow reference having prematurely broken out of a loop. I had originally checked on

<cfloop>

, and just wanted to see if the iteration higher order functions behaved any differently. They always reset it 😐

ah, gotcha! thank you for the clarification. i've always considered currentRow a "magic query variable" in that regard, hence my confusion as to what was being attempted, lol. thank you for taking the time to walk me through it!

Magic seems a good description.

It never would have occurred to me to try to access the query's metadata (

query.currentrow

) while inside of the higher-order functions. For some reason I wasn't thinking "loop" (where I have always previously used the

query.currentrow

metadata attribute). Thank you @Adam Cameron for opening my eyes to what, in hindsight, should have been somewhat obvious! 😄 Although clearly that doesn't work in ACF. 😢

I wouldn't say higher-order functions are loops, even though they can be implemented as such. And they shouldn't mutate the data structure being worked from, including

currentRow

. This seems especially fraught when executing in parallel. If you need the row number, that's what the second argument is for.

@mtbrown I probably didn't word that clearly, so fair point. As for not mutating data, I think there actually is one or more bugs filed because the higher-order functions in ACF actually mutate the original query (with queryMap, queryFilter, queryReduce, etc.).

Reminds me of this which I raised https://tracker.adobe.com/#/view/CF-4204497 Is not fixed despite having a status of fixed. I should really chase it but it's like talking to a void.... The amount of times I get "we'll get back to you" and then get radio silence I've given up.