New post
AllAccepted answers
Sean Connelly · Aug 23, 2017

That's a good question, but since none of us commenting here work for InterSystems, we can only assume it was an oversight.

Did you try Timothy's suggestion below to use the following as the fullwidth comma escape, he tried it out and it works.

，

I personally don't use Zen, so can only make suggestions, and this is as far as my suggestions can go on working around this limitation.

Sean Connelly · Aug 21, 2017

Out of context of the original code, I agree.

The actual implementation is there to stop an infinite loop on objects that reference each other as part of a JSON serialiser, see line 9...

https://github.com/SeanConnelly/Cogs/blob/master/src/Cogs/Lib/Json/Cogs....

I'm not sure the construction of seen($THIS) is so much incorrect, just problematic. Both seen($THIS) and seen(""_$THIS) will produce an array item with a stringy representation, and works perfectly fine with exception of the unwanted side effect.

My assumption was that $THIS used inside the $get was to be avoided for persistent classes, whilst I could continue to use the OREF for non persistent classes, hence finding that the persistent objects OID was a perfectly good workaround.

However, as it turns out seen(""_$THIS) prevents the unwanted behaviour and makes the code much simpler to read, so thanks to Timothy for testing a different idea out.

Out of interest, I have since discovered that the pattern of seen(+$THIS) is used extensively in Caché / Ensemble library code, where the + symbol will coerce the string to the ordinal integer value from the OREF. I was tempted to use this approach, but one thing I am not sure of is if ordinal values are unique across a mixed collection of objects...

Sean Connelly · Aug 21, 2017

>I suspect many users may view this as "WRC-lite" and have a sense of entitlement based on their ongoing financial commitment to ISC.

I came to the same conclusion.

If I was new to DC I could easily think that everyone providing answers is an InterSystems employee and not realise that volunteers are giving up their time and goodwill to help others. Regardless, its still nice to say thank you.

Perhaps it should be made more obvious who are volunteers and moderators?

Sean Connelly · Aug 9, 2017

The short (incorrect) answer that you are looking for is

set ..Count=..Count+1
$$$TRACE(..Count)

BUT, if you do this, you will notice that whilst Count does indeed increase with each message, it will not persist back to your settings.

Setting properties on an operation are just for convenience, they provide read access to the values held back in the production XDATA / the table Ens_Config.Item

If you want to dynamically update the setting values then you will need to look at the classes, Ens.Config.Production and Ens.Config.Item

But, as stated, it's best not to hijack static settings for a dynamic purpose. Updating the settings with every message will cause a production update event each time, and possibly other side effects.

If you want to track dynamic values at the operation level then have a look at pre-built services and operations that implement $$$EnsStaticAppData and $$$EnsRuntimeAppData, these macro helpers will save things like counts back to a persistent global.

Seems like a lot of hard work when you could just query the count and add a base value to it.

Sean Connelly · Aug 8, 2017

Probably not a good idea to change the production configuration settings with every operation call, each change will trigger a production update request on the production view.

If the customer wants to see a counter since a defined point then it sounds like there might be a point in time that can be used. In which case you get a count using SQL...

select count(id)
from Ens.MessageHeader
where TargetConfigName='CosTutorial.testIncrementalParameter'
 and TimeCreated between '2017-08-07' and '2017-08-08'