Infotable as property is not stable

[fmanniti]

I have two thing template: one is Sensor Template with Sensor Things and another is Element Template with Element Things.

Now, each Element Thing has many sensor "children" and each Sensor may have more than one element "father" so I gave to Sensor Things a property called Element_Father which is a infotable.

My problem is this infotable property doesn't look very stable because, after I join each child to its father and I populate my tables, if I make stuff like a new service on that property or if I shut the virtual machine down and turn it on again, sometimes the tables are empty.

Is there a reason why my infotable will delete their entries and how can avoid it?

My other clue was to add to sensor things a new property dinamically.

I mean that "Element_Father" would be a string instead of a infotable and, if a sensor has more than an element father, I would runtime add a new property called "Element_Father_2", "Element_Father_3", ... but I don't know if it is possible to add a property runtime.

[CarlesColl]

How do you store data on the Infotable Property?

[fmanniti]

Through a service:

In my mashup I have a grid widget with two columns: Sensor name and Assign (a boolean, which is editable);

My service takes as input a infotable which is the edited table and checks all the Assign values. If it's true, then I simply have this code which checks if the sensor is already assigned to the element and, if not, will assign it (in the code, "sensor" is called "point").

for(i=0; i<PointsToAssemble.length; i++){
    if(PointsToAssemble.Assign){
        var alreadyAssigned = false;
        for(j=0; j<Things[PointsToAssemble.PointName].element_Father.length; j++){
            if(Things[PointsToAssemble.PointName].element_Father.Name === me.name) alreadyAssigned = true;
        }
        if(!alreadyAssigned){
            var row = new Object();
            row.Name = me.name;
            Things[PointsToAssemble.PointName].element_Father.AddRow(row);
        }
    }
}

[ttielebein]

Dumb question, but have you marked  your infotable properties as persistent? If so, what version of ThingWorx are you in because there may be a related bug

[fmanniti]

I did.

It's not a dumb question because after I posted this I made the same question to myself, ehehe.

My TW version is 7.2.1

[ttielebein]

Darn, the bug I was thinking of was fixed in 7.2.0. The bug had to do with the values persisting when set manually on a thing. I am not sure that applies here. I am not really sure why you are seeing property values being erased if they are marked as persistent. You may want to open a support case for this

[fmanniti]

But, in general, is it possible that this happens when I write a new service which involves the infotable property?

I don't know, I'm just guessing

[jasong]

Maybe this has been fixed but since forever, you cannot write to INFOTABLE properties and expect them to persist (or have data change events fire) if you do not re-write the whole table. Generally, the work around is to do something like this:

var tempInfoTable = Things[myThingName].myInfoTableProperty;
//...
//Manipulate the tempInfoTable as needed
//...
Things[myThingName].myInfoTableProperty = tempInfoTable; //Table is written, persisted (if set to) and data change fires

[jasong]

I am also pretty sure this applies to JSON properties. Same work around.

[fmanniti]

Thanks Jason.

Anyways, I hope I don't go out of topic with this question:

I found out how to add a property runtime (I tested AddPropertyDefinition service but I didn't realize I must close the tab of the thing and open it again to view the property);

the question is: do you think that for my purpose is smarter to make the infotable or add runtime a property each time I have a new element father?

Because in first place I would say that infotable is better but, at least, STRING type properties seem to be more stable

[CarlesColl]

Hi Fabio,

Jason answer it's the correct one, that's why I've asked for your code, always: duplicate, modify, and set Infotable properties.

You can add properties at runtime, we do it, but you are modifying the model and Thing Restart may happen or may be necessary, take it easy.

If you are mapping properties, then you should go to Properties instead of and Infotable with values, as with properties you will have the full blown TW capacity for each property ( Events, Subscriptions, Logged Properties... )

By the way, if you modify correctly the Infotable it are Stable.

Carles.

[fmanniti]

Ok, good. That's what I wanted to hear

I'll do Jason proposal and I'll let you all know

[jasong]

The method by which you add does not matter, it's all the same behind the scenes. If you have a property to add, Composer UI works great. If you have 50 properties to add, sometimes its easier to write a script. But they are identical in their efficacy.