queryExecute result attribute bugs

I have found a few different bugs in the queryExecute function around the
result attribute. Here is the testcases:

All tested on lucee 4.5.1.000.

The bugs as I see them:

  1. There is no way I can find to create the result attribute variable in
    the local scope. See test 2, 3, 4
  2. Trying to use result=“local.result” silently fails to create the
    variable at all, in any scope. I believe there is no way to create any
    variable that has a period in the name. See test 2.
  3. Trying to var the result prior to the queryExecute call also keeps the
    variable from being created at all - it still silently fails. see test 3.
  4. Trying to var the result prior to the queryExecute and then set the
    result as result=result (without the quotes) also silently fails to fill
    the variable, see test 4
  5. related to #4, trying to use result=result (without the quotes) and also
    without creating the variable first throws a syntax error. I assume this is
    expected, the result attribute is expecting a variable name that it can use
    to create the variable - I would still argue this is bad form though, we
    should be able to provide the variable for the result value to go into .
    See test 5.

See test 6 for an example of the ability to assign to local variables
working properly with tags.

Also, as far as I can find there is no documentation anywhere around using
the result attribute with queryExecute, which cause a lot of fumbling
around on my part trying to figure out how to make it work, with these bugs
hiding how it should actually work.

I intend to raise these as issues in the bug tracker - it would be nice if
I could get independent confirmation that these are indeed bugs and not me
making a simple mistake - but I would also like to know from the team if
you would like these as one issue encompasing all of these bugs or raised
as separate issues.

I intend to file a separate proposal to overhaul the queryExecute()
function (or replace it) in the near future, but I believe these bugs need
to be fixed regardless.

See also this other bug with
queryExecute: https://bitbucket.org/lucee/lucee/issue/23/queryexecute-does-not-support-passing

Thank you very much for that John, I had tried something similar but not
exactly - at least this way you are able to get it to create the data in
the function local scope!

I’ve update to show this in the test
cases: https://gist.github.com/ryanguill/b6497628e951a3cffacd

Thanks again, this at least gives a safe workaround for the time being.On Tuesday, February 10, 2015 at 8:09:34 PM UTC-6, John Berquist wrote:

Hi Ryan,

I don’t really have anything to add except I definitely banged my head
against the wall a while back trying to get this to work. I ended up doing
something like the following (you may have noticed this already):

var result = { };
var result.data = queryExecute(“SELECT * FROM q”, {}, {dbtype=“query”,
result=“result.metadata”});

(note: doing result.data is superfluous to this example, what seemed to
matter was a result attribute variable name within a local scoped struct,
rather than immediately in the local scope)

I think this is a bug (or bugs!) as well, it would be great to have it
fixed.

John

On Tuesday, February 10, 2015 at 8:20:49 PM UTC-5, Ryan Guill wrote:

I have found a few different bugs in the queryExecute function around the
result attribute. Here is the testcases:

https://gist.github.com/ryanguill/b6497628e951a3cffacd

All tested on lucee 4.5.1.000.

The bugs as I see them:

  1. There is no way I can find to create the result attribute variable in
    the local scope. See test 2, 3, 4
  2. Trying to use result=“local.result” silently fails to create the
    variable at all, in any scope. I believe there is no way to create any
    variable that has a period in the name. See test 2.
  3. Trying to var the result prior to the queryExecute call also keeps the
    variable from being created at all - it still silently fails. see test 3.
  4. Trying to var the result prior to the queryExecute and then set the
    result as result=result (without the quotes) also silently fails to fill
    the variable, see test 4
  5. related to #4, trying to use result=result (without the quotes) and
    also without creating the variable first throws a syntax error. I assume
    this is expected, the result attribute is expecting a variable name that it
    can use to create the variable - I would still argue this is bad form
    though, we should be able to provide the variable for the result value to
    go into . See test 5.

See test 6 for an example of the ability to assign to local variables
working properly with tags.

Also, as far as I can find there is no documentation anywhere around
using the result attribute with queryExecute, which cause a lot of fumbling
around on my part trying to figure out how to make it work, with these bugs
hiding how it should actually work.

I intend to raise these as issues in the bug tracker - it would be nice
if I could get independent confirmation that these are indeed bugs and not
me making a simple mistake - but I would also like to know from the team if
you would like these as one issue encompasing all of these bugs or raised
as separate issues.

I intend to file a separate proposal to overhaul the queryExecute()
function (or replace it) in the near future, but I believe these bugs need
to be fixed regardless.

See also this other bug with queryExecute:
https://bitbucket.org/lucee/lucee/issue/23/queryexecute-does-not-support-passing

Hi Ryan,

I don’t really have anything to add except I definitely banged my head
against the wall a while back trying to get this to work. I ended up doing
something like the following (you may have noticed this already):

var result = { };
var result.data = queryExecute(“SELECT * FROM q”, {}, {dbtype=“query”,
result=“result.metadata”});

(note: doing result.data is superfluous to this example, what seemed to
matter was a result attribute variable name within a local scoped struct,
rather than immediately in the local scope)

I think this is a bug (or bugs!) as well, it would be great to have it
fixed.

JohnOn Tuesday, February 10, 2015 at 8:20:49 PM UTC-5, Ryan Guill wrote:

I have found a few different bugs in the queryExecute function around the
result attribute. Here is the testcases:

https://gist.github.com/ryanguill/b6497628e951a3cffacd

All tested on lucee 4.5.1.000.

The bugs as I see them:

  1. There is no way I can find to create the result attribute variable in
    the local scope. See test 2, 3, 4
  2. Trying to use result=“local.result” silently fails to create the
    variable at all, in any scope. I believe there is no way to create any
    variable that has a period in the name. See test 2.
  3. Trying to var the result prior to the queryExecute call also keeps the
    variable from being created at all - it still silently fails. see test 3.
  4. Trying to var the result prior to the queryExecute and then set the
    result as result=result (without the quotes) also silently fails to fill
    the variable, see test 4
  5. related to #4, trying to use result=result (without the quotes) and
    also without creating the variable first throws a syntax error. I assume
    this is expected, the result attribute is expecting a variable name that it
    can use to create the variable - I would still argue this is bad form
    though, we should be able to provide the variable for the result value to
    go into . See test 5.

See test 6 for an example of the ability to assign to local variables
working properly with tags.

Also, as far as I can find there is no documentation anywhere around using
the result attribute with queryExecute, which cause a lot of fumbling
around on my part trying to figure out how to make it work, with these bugs
hiding how it should actually work.

I intend to raise these as issues in the bug tracker - it would be nice if
I could get independent confirmation that these are indeed bugs and not me
making a simple mistake - but I would also like to know from the team if
you would like these as one issue encompasing all of these bugs or raised
as separate issues.

I intend to file a separate proposal to overhaul the queryExecute()
function (or replace it) in the near future, but I believe these bugs need
to be fixed regardless.

See also this other bug with queryExecute:
https://bitbucket.org/lucee/lucee/issue/23/queryexecute-does-not-support-passing

Thanks for highlighting this Ryan, I’m encountering the same on Lucee 5.

Thanks John for the work-around.

AdrianOn 11 February 2015 at 01:20, Ryan Guill <@Ryan_Guill> wrote:

I have found a few different bugs in the queryExecute function around the
result attribute. Here is the testcases:

https://gist.github.com/ryanguill/b6497628e951a3cffacd

All tested on lucee 4.5.1.000.

The bugs as I see them:

  1. There is no way I can find to create the result attribute variable in
    the local scope. See test 2, 3, 4
  2. Trying to use result=“local.result” silently fails to create the
    variable at all, in any scope. I believe there is no way to create any
    variable that has a period in the name. See test 2.
  3. Trying to var the result prior to the queryExecute call also keeps the
    variable from being created at all - it still silently fails. see test 3.
  4. Trying to var the result prior to the queryExecute and then set the
    result as result=result (without the quotes) also silently fails to fill
    the variable, see test 4
  5. related to #4, trying to use result=result (without the quotes) and
    also without creating the variable first throws a syntax error. I assume
    this is expected, the result attribute is expecting a variable name that it
    can use to create the variable - I would still argue this is bad form
    though, we should be able to provide the variable for the result value to
    go into . See test 5.

See test 6 for an example of the ability to assign to local variables
working properly with tags.

Also, as far as I can find there is no documentation anywhere around using
the result attribute with queryExecute, which cause a lot of fumbling
around on my part trying to figure out how to make it work, with these bugs
hiding how it should actually work.

I intend to raise these as issues in the bug tracker - it would be nice if
I could get independent confirmation that these are indeed bugs and not me
making a simple mistake - but I would also like to know from the team if
you would like these as one issue encompasing all of these bugs or raised
as separate issues.

I intend to file a separate proposal to overhaul the queryExecute()
function (or replace it) in the near future, but I believe these bugs need
to be fixed regardless.

See also this other bug with queryExecute:
https://bitbucket.org/lucee/lucee/issue/23/queryexecute-does-not-support-passing


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6571993a-38a3-45ad-b9cc-efccfdc364e7%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6571993a-38a3-45ad-b9cc-efccfdc364e7%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.