FileMaker 18 Data API > Create Record - JSON visualization and building

Yes, that is the example I used.
Why would building an array be any different, though? In fact, from a data structure perspective, it feels like it would be easier.

You might have scenarios where you combine the ease of Set Variable ( for individual objects ), and Insert Calculated Result ( for building the array itself ).

I agree, key collision could be an issue. But it's easy to check for that first, and replace that individual line. ( Something along the lines of what Bob Bowers showed in 2012 in his Advanced Reporting session ).

Overall, evaluating the situation is necessary. If you are building a large array, something that runs in 1.6% of the time is probably worth that little extra to get it as fast as possible. Maybe not always, but very often.

Yep, we're making the same point. If you are building an array, Insert Calculated Result will be faster because you are taking advantage of its ability to append a StringBuffer. I'm dynamically append an array in my first picture above.

It's like in JavaScript using myArray.push('newStr') instead of myString += 'newStr'. The latter is slower because of the +=, i.e. "copy yourself and add a new suffix". in FM parlance, Set Variable [ $var ; $var & "newStr" ]

But if you are not utilizing the append feature of Insert Calculated Result, you won't see any of the performance improvement that we've both demonstrated.

2 Likes

Sometimes you have to work with APIs that make you... some are pretty arcane in their JSON structure and some require a lot of data (text analysis APIs for instance,...)

1 Like

Bit of an edge case to watch out for...

Just tested putting "}{" in a field. ( }{ looks like people having a conversation! )

Looks like there is both risk and reward to various approaches.

By the way, this "}{" gotcha can be avoided if each JSON object or array is on a single line with returns in the data JSON escaped/encoded.

Save the JSONFormatElements ( json ) for after.

1 Like

As in thousands of keys?

Also, I still don't think there's a performance advantage to building a big object like this. you could simply do one big JSONSetElement() in a Set Variable with the same result, assuming the calc character limit didn't stop you.

(To be clear I do recognize the performance advantage vs setting one key at a time in a loop. I'm just referring to one gigantic JSONSetElement() being just as fast.)

Sometimes that's difficult to use a single JSONSetElement depending on how you get the data. Like if I was building an array for a virtual list, or to pass back out to an API, looping over records to get the data...or having to pull the data from multiple tables.

1 Like

I really wanna be clear here. I always use Insert Calculated Result for building arrays dynamically (if they're composed of objects or arrays).

That is precisely where the advantage of ICR is, in appending to a string.

What I've personally not encountered is a JSON Object{} with enough named keys to justify using the }{ replacement method. I'm happy to have this technique }{ in the toolbelt when that day comes though, thank you!

1 Like

I've most often used this approach ( with an Object vs an Array ), to create a JSON index. It makes it really easy to call the data back out. I don't have to loop an Array, just pick out the data I need from the index using the productID. It stays super fast, and I can list out tens of thousands of products super fast.

At times, depending on what I'm doing with the list, I may use a repeating variable for speed, but that happens much less often than it used to.

{
	"40000123": {
		"description": "product description",
		"price": 500
	},
	"4000543": {
		"description": "product description",
		"price": 600
	}
}
2 Likes