tracker issue : CF-3818776

select a category, or use search below
(searches all categories and all time range)
Title:

Updating structkey presevation doesn't work unless you edit the CFM

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/TooManySideEffects

Reporter/Name(from Bugbase): Raymond Camden / Raymond Camden (Raymond Camden)

Created: 09/04/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final / CF 12.0

Priority/Frequency: Major / All users will encounter

Locale/System: English / Mac 10 All

Vote Count: 3

Related Bugs:
CF-3913844 - Similar to


Imagine you have a CFM making a struct and you serialize it. You then change Application.cfc to add (or modify!) 

	this.serialization.preservecaseforstructkey = true;

Your CFM will *not* reflect this change until you edit the CFM.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3818776

External Customer Info:
External Company:  
External Customer Name: cfjedimaster
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

It really worries me how this has been implemented, if this is the case. Shouldn't work this way. -- Adam
Vote by External U.
11052 | September 04, 2014 04:40:47 PM GMT
Hi, It seems like template is being cached. Navigate to ColdFusion Administrator > Server Settings > Caching 1. Uncheck "Trusted Cache" and try this. 2. You can also click "Clear template cache" this button to clear the template cache. Click the button below to clear the template cache. ColdFusion will reload templates into memory the next time they are requested and recompile them if they have been modified. It does not compile the template again, if there are no changes. Regards, Nimit
Comment by Nimit S.
11037 | September 05, 2014 12:05:35 PM GMT
Trusted cache was not turned on. If clicking #2 also fixes it, it is still a bug. Whether I have to go to the CF Admin and hit the button or edit the CFM, it is still a bug, right?
Comment by External U.
11038 | September 05, 2014 12:23:29 PM GMT
The flag is used at to preserve the original case and this happens at code generation and compilation time. Once the code is generated this flag will not be used until there is a fresh need to recompile the cfm template. So you need to edit the template to reflect the changes and there is no other way. But we can additionally provide a config property through which template chache will be cleared once the preservecaseforstructkey property is reset in app.cfc
Comment by Awdhesh K.
11039 | September 11, 2014 01:29:27 AM GMT
"The flag is used at to preserve the original case and this happens at code generation and compilation time" Wow. Really? That sounds a bit jerry-built, dunnit?
Comment by External U.
11040 | September 11, 2014 02:01:10 AM GMT
Any application level changes implemented in Application.cfc should take precedent.
Vote by External U.
11053 | September 25, 2014 08:00:35 AM GMT
+1 ......................
Vote by External U.
11054 | November 24, 2014 02:39:46 AM GMT
I can say for a fact that 99% of users will assume the case will change. If trusted cache is turned off, and the server reads in my CFM on every request, file change or not, then this should work, and it not working is a bug. You have to see that, right? I strongly disagree with adding *another* flag. While I'm happy to see more and more control given to the user in App.cfc, we also have a responsibility to ensure these settings are clear, concise, and actually sensible. In my opinion, adding another one just to fix this bug is a mistake.
Comment by External U.
11041 | December 22, 2014 09:57:17 AM GMT
Interestingly, I see this is marked "Fixed In Build CF 12.0". So, some questions: 1) Does the fix involve another flag? 2) Will the fix be backported to the *current* version (the version this ticket was actually filed against)? 3) Will we be able to test v12 fixes soon? =) 4) Can more of your internal comments please be made public so that we don't have to ask questions like #1 and #2? Thanks!, -Aaron
Comment by External U.
11042 | February 15, 2015 02:03:09 PM GMT
1. No, the same flag would be honored at runtime instead of compile time. 2. Since the changes are quite significant, we would not be porting it back for the update. It would be part of CF 12. 3. You would get to know :-)
Comment by Rupesh K.
11043 | February 16, 2015 03:42:42 AM GMT
You missed #4.
Comment by External U.
11044 | February 16, 2015 03:45:42 AM GMT
Hi Rupesh, Thanks very much for confirming all of that! Very cool about #1 and especially #3 =) And I think this is the 1st time I've received an email notification of an engineer adding a comment, so -maybe- that notification issue has been fixed. And I'm also w/ Adam that it'd be helpful if a "This is how the ticket was fixed...." comment can be added before closing tickets when multiple possible solutions were discussed. And, of course, there are other valid cases for adding such a comment. I think sometimes comments are intended to be public, but just inadvertently marked internal. Thanks again for replying!, -Aaron
Comment by External U.
11045 | February 16, 2015 08:45:07 AM GMT
Agree.
Comment by Rupesh K.
11046 | February 17, 2015 01:41:48 AM GMT
This fix has been reverted because of a backward compatibility issue.
Comment by Nimit S.
11047 | February 18, 2016 08:49:29 AM GMT
So can you recap where things lie in CF11 and CF2016?
Comment by External U.
11048 | February 18, 2016 08:56:52 AM GMT
Hi Ray, I confirmed this isn't fixed in CF2016. Related thread: http://prerelease.adobe.com/r/?6cbc7c6e23db417cabc5ef39a85d2c15 Thanks, Nimit, for letting us know. -Aaron
Comment by External U.
11049 | February 18, 2016 11:31:35 AM GMT
I'd just like to note that I find it interesting how many issues there are (and have been) w/ per-App settings not taking effect at the right time. Thanks!, -Aaron
Comment by External U.
11050 | February 18, 2016 11:33:16 AM GMT
As per current design, the struct key was being maintained by preserving its original case during compile time. To honor this there is an application and the admin setting. The cfm files need to be re-compiled if a new value of this setting has to take effect. To avoid re-compilation, the solution was to honor this setting at runtime and we tried moving this code to runtime work-flow as well. But moving this logic to runtime has caused few regressions and finally has to be reverted back. Regression that we faced are: 1. cfclient struct keys got altered and all related test case started failing. 2. There was some issue in other part of serialization. Moving the code to runtime is technically not possible. Now, we have only one option to honor this setting and that is honoring it at compile time.
Comment by Awdhesh K.
11051 | August 17, 2016 12:27:49 AM GMT