query question, if you wanted to turn a query result into an array of structs after getting the results back as a query object, how would you do it? the data would then be serialized for use with javascript, if there happens to be a simple action that combines both steps

I usually do it with QueryReduce.

queryObj.reduce((arrOfStruct, row) => arrOfStruct.append(row), [])

And then feed that to SerializeJSON.

Beat me to it.

nice, I had also thought about using a query of query like

qryAsArray = queryExecute("select * from numbers",{},{dbtype="query", returnType="array"});

it seems they are both pretty fast, the query of query seems to be faster at scale. https://trycf.com/gist/a69054b9dbf4ab17da28026d962db12b/lucee5?theme=monokai I was thinking there was another way to

serializeJSON…… as array

or something as well but couldn’t remember exactly

So do you need to deal with ONE MILLION rows? If not, I'd probably not base what code I'd write on a naive test that just uses a large number just so you can get a result that is three orders of magnitude less that the starting number. That kinda indicates the performance... isn't actually a consideration. Just write the code that is clearest in intent. FWIW, I think the QoQ code reds just fine, but I don't think it's as idiomatic of the overall intent as the reduce operation. On the other hand... more CFMLers will probably be more likely to understand QoQ than reduce, so that might be points in QoQ's favour. If I had ONE MILLION rows... I'd probably employ the punchline of an old Irish joke "If I wanted to get to there I wouldn't start from here". Don't get the ONE MILLION rows in the wrong format in the first place. Get it in the right format. But also... probably don't do anything with CFML that involves ONE MILLION rows. [it's best if you effect Dr Evil's voice in yer head every time I emphasise "ONE MILLION"]

🤣

I always wondered why we, as programmers, even agree to return thousands of rows back to a browser. 10's, ok, Hundreds, iffy (unless maybe a web service). But thousands or more? Give 'em a spreadsheet. Anyone ever seen a use case where thousands is OK to send back to the browser? My limit has always been 50, chunked if necessary for more, but anything other than that requires a serious discussion with my client on what they actually need - and 111% of the time it aint thousands of rows.

my use case is for flexible graph reporting, it is easier to return the data and allow them to group and filter on the front end then to do ajax requests each time. but in fairness, this is an exception to the rule

Have you ever played with Excel Web queries? They are lightning.

i have not

The basic concept is one worksheet has the graph, the second has the data. The second sheet, when you open the excel file fetches the data from a simple table web page. You should play around with it a bit in your free time.

interesting, could you post a link to an article about it?

Not at the moment, I'll have to hunt one down, but I'll do it before I hit the sack this evening

oh ok, so you basically set up the data vis in the excel sheet and then point it to an endpoint? how do you handle auth?

With a key in the URL is all I ever needed, it was Intranet work. Never had to explore beyond that.

I use Grid by Telerik, I can do client or server side pagination for viewing purposes and user server side for ExcelExport or PdfExport. This is the only use case for 1,000+ rows. paginatin is usually at 20 rows

Lots of solutions, just showing you another Rabbit Hole.. lol

ofcourse CF is handling all the server side

yeah, always interested in what others are using for solutions

its fast, simple to set up, and Excel usually familiar (and free) to the data miner you are building the web pages for. Frustration free packaging

that sounds interesting.

nothing fancy, just using cachebox with ConcurrentStore

i see - so same host as your application?

yep

Sorry, just knocked off for the day, I'll have to show the excel query stuff another time..