12 Replies Latest reply on Nov 17, 2016 5:57 PM by jasong RSS
    fmanniti Creator

    Infotable as property is not stable

    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.

      • Re: Infotable as property is not stable
        carlesc Ninja

        How do you store data on the Infotable Property?

          • Re: Infotable as property is not stable
            fmanniti Creator

            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[i].Assign){
                    var alreadyAssigned = false;
                    for(j=0; j<Things[PointsToAssemble[i].PointName].element_Father.length; j++){
                        if(Things[PointsToAssemble[i].PointName].element_Father[j].Name === me.name) alreadyAssigned = true;
                    }
                    if(!alreadyAssigned){
                        var row = new Object();
                        row.Name = me.name;
                        Things[PointsToAssemble[i].PointName].element_Father.AddRow(row);
                    }
                }
            }
            
          • Re: Infotable as property is not stable
            ttielebein Collaborator

            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

            • Re: Infotable as property is not stable
              jasong Creator

              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
              
              • Re: Infotable as property is not stable
                fmanniti Creator

                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

                  • Re: Infotable as property is not stable
                    carlesc Ninja

                    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.

                    • Re: Infotable as property is not stable
                      jasong Creator

                      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.