Bug while using the decimal character (".") in string split and concatenate operations

Shreyase

I just observed that string manipulations that involve splitting or concatenation, and uses "." as the separator are consistently failing. 

Using "." as separator to split "file.name" gave me ['f', 'i', 'l', 'e', '.', 'n', 'a', 'm', 'e'] instead of what I was expecting - ['file', 'name']. 

Similarly using "." as the separator in concatenating 'file' and 'name' gives 'filename' instead of 'file.name'. 

Currently, I have worked through this by concatenating "." converted using to_text() and then appending the rear string. 

Sean Montgomery

wow good catch. we will be taking a look at this and should have this resolved in this weeks release end of week.

Sean Montgomery

 tracked down this issue.

The "." is getting mistaken for a decimal number.

Quick fix would be to clear out the input box, type in the "." without quotes, and then select "text" from the const group. That will force the period to text.

The mistaken decimal identification will be in tomorrows release, but you can use this workaround in the meantime.

Sean Montgomery

Build deployed. If you type in a ".", then it should remain as text instead of decimal.

Shreyase

I really appreciate these quick updates!
Actually, the problem with dots also extends into the JSON handlers.

Some of the JSONs I am dealing with have "." in their key names. Agreed, putting."."s in JSON key names isn't the best of the practices, but Xano does have a one-way trap. 

The stack creates a JSON object from an input string. This goes well as expected and the dots are not a problem. The input JSON is a flattened JSON with no hierarchies, but only dots, and so is the JSON object that gets created. But when I try to use the get/set filter on the object, I cannot access any of the existing keys nor can I add any. Turns out that the get and set filters use dots as a hierarchical separator (which in hindsight is a very good behaviour), so when I set 'conf.level' : '0.5', it creates it as: 
'conf':{'level':0.5}

I have overcome this by modifying the incoming JSON schema, but what's the best way to overcome this issue?