Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Enhance cfquery or anything that returns queries to return array of structs

Description

Hibernate has a feature that returns array of maps instead of array of objects. Returning array of maps is consistently faster than even query objects. I would like to propose the ability for cfquery or any other tag/function that returns queries to return array of structs instead.

Merits For This Ticket:

1. Try to enable the return of array of structs for ORM related functions for improved performance and the other things below:
2. Enable it for cfquery, storedproc, etc in order to enable it for conversion to modern JS based apps or restful apps.
3. Enable it for having direct ability for map/reduce/filter abilities.

Adding a returntype would be nice for the cfquery, proc and ORM options

<cfquery returnType="query|array"> queryExecute() options {returnType="query|array") entityLoad() options {returnType="query|array")

Activity

Show:

Sean Corfield 2 May 2017 at 16:50

I would say that – at the very least – such features deserve an official blog post with rough docs so end users can try things out. Saying "Oh, it's experimental so we hid the docs" is a cop-out in my opinion: put it in the docs, flag it as experimental, and ensure end users actually know about these things by public means (not just as a comment on an issue, as here, or a single post to a mailing list that has lots of other "noise" and doesn't reach all your users).

Adam Cameron 2 May 2017 at 13:09

I hasten to add I am not making any sort of judgement or indictment with my comment above. Just that we're talking about process organisation, and it seems the "definition of done" ain't quite right here. And also yer right: this is perhaps not the place for this conversation. Sorry.

Back on topic... I think before any work like this is done, "we" need to stop and have a think about the bigger picture, and not focus on just the title of the ticket, which I think has too narrow a scope, and might be begging the question more than suggesting a good solution.

Raymond Camden 2 May 2017 at 13:03

"Obvs. Lucee has a minimal pool of resources, but that perhaps just means things take longer; not that steps are skipped." And I think this is the crucial point. As an end user, I'd rather have fewer well done features then more that are not complete. Btw, I'd be happy to take this discussion someplace else that is more appropriate. The docs are probably the #1 issue I've run into with Lucee, it isn't this one thing alone, so it's definitely (imo) a larger issue to debate.

Adam Cameron 2 May 2017 at 12:53

My attn has been drawn back to this ticket

Just one thought on the disconnect between "code" and "docs", esp in the context of 's comment above.

Perhaps the issue is the devs see the work for a ticket as being all about the code, and the docs are separate.

I'd rather expect for a given piece of work, there would be these components:

  • issue raised (user)

  • issue accepted (TAG & LAS: ie it's a business decision to accept an issue, not a dev one)

  • solution planned (TAG & dev)

  • solution signed-off (TAG & LAS)

  • coding work done, via TDD (dev)

  • docs done ("volunteer")

  • QA done (QA, possibly with additional volunteers, but specifically not dev)

  • release scheduled (TAG & LAS)

  • release (dev or TAG)

All of those steps might be done by different people (eg's listed in parentheses). They also might have varying degrees of actual work, from "almost zero" to "really a lot", but none of them are ever not done at all.

It looks to me the devs here (like most devs, I hasten to add!), are only seeing that "coding work done" as the "work" relating to a feature.

it's completely fine for dev work to be completed before the docs are done. But the docs ought to be done before the QA part, and subsequent parts are done.

Otherwise the work doesn't meet an appropriate "definition of done", and it's not ready to be released.

Obvs. Lucee has a minimal pool of resources, but that perhaps just means things take longer; not that steps are skipped.

Raymond Camden 2 May 2017 at 10:59

+Michael Offner: That's fair, but what is the gameplan for this feature since it has been many months? Is there a general place to see all features like this? If the idea is, "it needs to be tested in the wild a bit more", then is there a rough doc for features like this? Also, does "Deployed" as a status imply this as well? Is there another status for "done and documented" that would be after Deployed?

Fixed

Details

Assignee

Reporter

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Fix versions

Priority

Created 9 November 2015 at 18:32
Updated 2 May 2017 at 16:50
Resolved 12 October 2016 at 08:25

Flag notifications