I’ll first describe our actual use case but I created a “demo” application that’s more universal.
We have a need to track gauges used to perform inspection on our parts. The idea being that the operator will scan the gauges into the application for DHR purposes. We decided to store this data as part of the app completion data so the only way to accomplish that is to use object arrays.
Unfortunately, there’s VERY few methods to deal with or modify object arrays within an application which ended up making for some very interesting work arounds, but I digress. This post will only cover simple reference tracking and I’ll be working on a Part 2 another day.
What are Object Arrays?
The most common use case for object arrays are the results of SQL connector functions where multiple records are returned, but that’s really two questions in one, so first let’s start with What are objects in Tulip?
They’re basically a way to store and use a complex JSON object within an application. Once created you can alter the contents of the object using normal Data Manipulation
methods.
Example 1:
{
"object": {
"item 1": "text value 1",
"item 2": integer,
...
}
}
NOTE: In Tulip, once you create an object and use it, its structure and datatypes are fixed and cannot change.
Object Arrays are simply an array of objects with a zero based index.
Example 2:
{
"objects": {
0: {
"Item 1": "text value 1",
"item 2": integer1
}
1: {
"item 1: "text value 2",
"item 2: integer1
}
...
}
How Do You Use Object Arrays for Reference Counting?
This is actually somewhat complicated, but not nearly as complicated as Part 2 will be…
Example 3:
First let me show you the demo, and then we’ll break down how it works:
As you can see, instead of simply appending the duplicate animals, it actually updates the count to the sum of the existing object and the new one.
The Nitty-Gritty Details
First you need to create an object with the format you need with all the elements you want to store and their data type. For my demo I’m counting animal types and their count:
Then you need to create an object array with the exact same formal. You can do this manually but it’s easier to create the object array on the fly. Tulip will take care of making sure the names and data types are the same.
NOTE: Ignore the “Requirements Met?” part, that’s for Part 2
Now comes the fun part. All the logic to make this work.
Here’s a snapshot of the triggers and their orders:
-
Gather existing items: This checks to see if this is the first time an object is being added or if we need to modify an existing object.
We can only check if the array is empty, so if it it’s, the trigger’s a no-op, otherwise
MAP_TO_TEXT_ARRAY
is used to create a simple array we can actually use to find the index of an existing object. -
Load if it exists: Here we “load” (and I use the term loosely) the existing object if it’s already been added before:
We make use of the simple array created by the previous trigger to find the index of the object we want to “load”. Then because objects in arrays cannot be modified in place, we move it into a new object with the same structure called
Working Object
and store the sum of the previous count and new count into a variable calledItem Total Count
.If this is the first time we’re seeing this item, just store the count into the
Item Total Count
variable as that makes the logic easier in the next trigger where we store the count.NOTE: Even if this is the first time the item type has been encountered we copy the
Item
from theInput Object
to theWorking Object
just to make downstream logic simpler. -
Add or modify object array: Now we append the
Working Object
back onto theObject Array
Because we merged the data to the
Working Object
already, we just need to push it on to theObject Array
. This could be added to the previous trigger but we would have had to put in the push logic twice which I try to avoid when possible.