Another CF2023 bug from what I can tell. "*Preser...
# cfml-general
d
Another CF2023 bug from what I can tell. "*Preserve case for Struct keys for Serialization" ignores local scope. I have it turned on, in ACF2023, this code:*
Copy code
local.body = {};
local.body.amount = 2000;
writedump(serializeJSON(local.body));abort;
Produces: {"AMOUNT":2000} It should be lowercase for AMOUNT. In ACF2016, it correctly outputs: {"amount":2000}
c
Dave, I suspect there's more to what you're seeing than meets the eye. First, I ran that code on CF2023 (and 2021 and 2018) and got the same result as CF2016. Second, maybe you're having some error that's keeping the this.serialization struct from being set as you think. Can you add this to your code, to see what it reports:
writedump(getapplicationmetadata().SERIALIZATION);
Third, you refer to using the local scope but don't show this code running in a function/udf/method. Can you confirm that's what you're doing? Finally, I put all this together into a 2-file app at cffiddle.org, specifically https://cffiddle.org/app/576ece54-457b-4196-8182-e491f6a84781. But folks need to login there (using a google account) to see such code. So I have also zipped up the sample code, and though I can't see a way to attach that 2-file zip here, I can offer this dropbox link to it. Let's see how things go for you, with that or with your reply to the question above. If it does still happen for you wit this code, maybe identify more about your cf2023 setup, so we can find how it differs from where the code does work.
Correction to that dropbox link.
Also, I want to clarify that while your original post referred to the setting by its name in the CF Admin, and I demonstrated things in the code using the application-based setting for it, I confirmed that I still got the same behavior either way. Again, just trying to help you narrow in on what you're observing.
d
Hi @carehart, thanks for responding. Yes local.body was in a cffunction, the preserve case is set in CFADMIN Let me switch back to CF2023 and I'll dump what you suggest. I simply switched exactly the same code (same file) between the two, with the same setting in CFadmin and local vars don't respect the case.
Copy code
<cfcomponent output="false">
	
	<cffunction name="test" output="false" access="public">    

		<cfscript>		
				
			local.body = {};
			local.body.amount = 2000;

			writedump(local.body);abort;

		</cfscript>

	</cffunction>

</cfcomponent>
Call test() and it dumps AMOUNT, not amount, with CFADMIN > Server Settings > Preserve case for Struct keys for Serialization. ticked on
r
Have you tried setting
_this_.serialization.preserveCaseForStructKey _=_
_true_;
in the Application.cfc?
c
First, Dave, now that you clarify you were doing this in a CFC method, I can confirm now that I see the behavior. BTW, it is NOT specific to the local scope (in my testing) but exhibits the unexpected behavior even without it (and regardless of the app-level preserveCaseForStructKey). And Rodney, that is indeed what I had offered in the example application.cfc I put together (but I realize you'd not know it without looking at the code). It was also why I asked him to test the result of getapplicationmetadata for that serialization struct, in case it was significant. Again, it wasn't in my test of a UDF in a CFM (which always worked honoring that). And it's also not significant (I find) in testing it now as a method in a CFC. Dave, I see you filed a bug report (https://tracker.adobe.com/#/view/CF-4218021)--and that you clarified there it's about a CFC method. I've added a vote. I wonder if there's not SOMETHING we can do to get this working for you short of them fixing the bug. I have to run to prepare for a client call about to start. Maybe someone else will see an opp for this.
d
Maybe I'm slipping a gear, or out of date, but I'd expect
local.body.amount = 2000
to result in the key AMOUNT, serialized or not. If you want the key to be "amount", you need to create it with bracket notation, like
local.body["amount"]
. (That's assuming you don't care about the case of the body key; if you do, it needs bracket notation too.)
m
The bug listed here (https://tracker.adobe.com/#/view/CF-4218021) was determined by the poster to not be a bug and has been withdrawn until details of exactly why and when the issue occurs can be determined. @davequested can you please link me to the bug report you filed for this?
c
My bad, @Mark Takata (Adobe). I gave the link to the older (closed) one by mistake, as I'd been looking at both. Dave's is https://tracker.adobe.com/#/view/CF-4218099
@Dave Merrill on your question, it's that CF has long been able to implicitly infer that code like Dave has means to create a struct key (if it does not exist already), as well as a struct (if it does not exist already, though in Dave's code he was indeed creating the struct using the brace notation).
m
OK, makes sense. Thanks Charlie. Taking this on internally in Jira with the team.
c
I have some news: Dave, if you were to change from using that implicit struct creation (with braces) and change that first line instead to
local.body=structnew("casesensitive")
, then the code WOULD work. That's indeed a change in behavior in cf2023 (it is not needed in 2021), but for now perhaps it could be a work-around for you, and a clue for Adobe
d
@carehart Re your post tagging me, I'm confused. Are you talking about this post which I replied to? Unless I'm lost in space (always possible), the code he posted isn't creating a struct implicitly by defining keys under a struct that doesn't exist, which looks like what you're referring to, it's completely explicit. And the issue isn't about creating the struct, it's about the case of the struct keys.
c
@Dave Merrill, if you view things as a thread here in slack you will see that we are all indeed party to the same discussion. 🙂 BTW, before you wrote your last comment, I had tweaked my earlier one. That slight revision would address your concern, I think. Even so, what I've said (about your proposed change) still stands. It would not change his behavior. But see my next comment after that above, where I propose that changing from that {} approach can offer a workaround--though I'd agree it seems it should not be necessary
👍 1
d
Hi @carehart, legend as always, and thanks for confirming the issue exists your end. Thanks @Mark Takata (Adobe) for getting this in front of the team to fix. Happy to test a pre-release if that helps. As you can imagine we don't want to go through all our code and change to structNew 😉 If anything we're going the other way! But thank you for providing a work around. At this stage we've switched back to ACF2016 and will wait till this issue is fixed as it breaks most of our app and we can't continue testing ACF2023. Case is massively important for us as we do a lot of JSON serialization and XML transforms, where case in the end result is important.
🤝 1