slight `queryparam` change with lucee 5.3.9.91, si...
# lucee
z
slight
queryparam
change with lucee 5.3.9.91, since 5.2.6, it would automatically set
list=true
if it was an array, this automatic behavior has been disabled https://luceeserver.atlassian.net/browse/LDEV-3893
a
As this is a breaking change, should it be going in before the next major version (ie: 6.0)? Also, just out of interest, how are doc changes for this sort of thing handled/managed? This (new) change conflicts with the docs... you'd want to make sure the docs are updated simultaneously with the behaviour change, right?
All that said, I think the existing behaviour makes sense. An array is intrinsically a collection type, so it makes perfect sense for the
list
attribute to be inferred here. It's needed with other (simple) values as the inference can't really be made reliably, eg:
"one,two,three"
could be a value or a list of values. Both are valid equally possible). Is there any situation where an array could be a valid value for a parameter, and for it to not be treated as a list of values? I think the rationale for LDEV-3893 is bogus. It's not for the queryparam code to care whether the SQL statement is syntactically correct. There are plenty of other ways in which a mis-placed param can cause invalid SQL (eg:
SELECT col2 FROM table WHERE col1 :myparam
. SQL is broken cos they forgot the
=
operator). It doesn't make any sense to me to break a good feature (and also break backwards compat outside of a major version bump) to try to address devs writing invalid code. They will know their code is invalid as soon as they run it, after all.
b
I had similar questions. I'm curious about what specific scenarios we're improving and if we're just making some scenarios worse.
1