9 Replies Latest reply on Apr 22, 2013 4:00 PM by cmanhard

    Two Element Version Issues

    Rick Davin

      This is my first foray into versioning for an AFElement and I have 2 issues detailed below.  My AF client version is 2.5.1 and my AF server version is 2.5.0.  I whipped together a small test template with an AFAttribute that is a configuration item, which is a string attribute that cycles among { “First”, “Second”, “Third”, “Fourth”, “Fifth”, and “Sixth” } starting on Sunday, 1/1/2012, and incrementing every 7 days.  Here’s a brief shot of the version history:

       

       1307.Show-History.png

       

       

       

      So far, this looks good to me, meaning it is what I expected.  My first issue of something I did not expect is when I did a Time Series in PSE (with the default null QueryDate):

       

       1205.version-time-series.png

       

       

       

      The time series cycles correctly, but what I was not expecting was 2 values per version event.  I was only expecting the 2nd value in each rectangular pairing.  So it seems that the versions overlap as one is created and the other one ends.  This doesn’t seem right to me.  I tend to think that the very instant a new version is created that the previous version should be out of scope. 

       

      Other than multiple values at the same event, the Time Series works as to be expected, as long as PSE’s QueryDate is null.  My 2nd issue is that when I specifically set the QueryDate that the Time Series gives me unexpected results.  Let’s choose Jan 18, 2012, when the configuration item should be “Third” effective on 1/15/2012.  I also am expecting it to be “First” on 1/1/2012 and “Second” on 1/8/2012.  But here’s what I get:

       

       1411.Time-Series-Jan-18.png

       


      Lucky for me, we really don’t use QueryDate, other than creating element versions.  If I’m interested in a time range, I use a null QueryDate and put the range of interest in the Time Series dialog.  So this shouldn’t be a problem for us.  I only stumbled upon as I was testing, since I am a newbie to element versioning and feel a strong need to kick the tires twice and give a test drive before putting it into production.  I can see that one could argue that the above results are correct or incorrect depending upon how you want to interpret it.  If you interpret it as “set the QueryDate and give me the one element version that is applicable, then show me data against that one version” then the results are correct.

       

      So the 2nd issue doesn’t seem to be a bug as much as intentional behavior.  However, I would categorize my 1st issue of multiple values at version created events as a bug.  At least from where I am standing.

        • Re: Two Element Version Issues
          Rick Davin

          I know this is UC week and others are busy or traveling as I type, so if you don't mind I'll just talk to myself.  Here's why I think its a bug that I get multiple values at a 'version created' event: the exact point in time that an element version is created and that its new value becomes effective should also be the exact point in time that the previous element version is rendered obsolete and that its old value should become ineffective.  So in my opinion since the older version should be ineffective, then it should not be produced in the AFValues fetch.

            • Re: Two Element Version Issues
              Roger Palmen

              I'm listening in on your talking!

                • Re: Two Element Version Issues

                  Hello Rick,

                   

                  I was listening too and have tried reproducing your issue. I get similar results when using "Interpolated" Boundary Type. Can you please check if "Inside" delivers what you expect?

                    • Re: Two Element Version Issues
                      Rick Davin

                      Gregor,

                       

                      Interpolated, Inside, and Outside all deliver the same, and still incorrect, results.  As my configuration item is a string attribute, then the boundary type only affects the start and end times.

                        • Re: Two Element Version Issues

                          Hello Rick,

                           

                          I've contacted you by email yesterday but I understand you prefer keeping the discussion inside the forum exclusively what's pretty much ok to me.

                           

                          However, I am doing hard to understand your issue or I am not able reproducing it. Maybe I only get confused by the fact that you were talking about versioning.

                            • Re: Two Element Version Issues
                              Rick Davin

                              Gregor, as my post has nothing proprietary to my application, I see no need for private emails.  Such a notion runs counter the very philosophy of why there is a vCampus in the first place.  I believe in crowd sourcing and as is too often the case with PI knowledge, much of it exists "behind garden walls", meaning its very insulated and isolated from public view.  I don't want to get stuck in a private email where one person with strong skills in one area may have weaker skills in the actual topic-at-hand (element versioning) when I can instead have 10 or 100 or 1000 other people with varying skills also help out on the topic.  And for those that lack the skill but have the interest, they can learn from the public posts.

                                • Re: Two Element Version Issues
                                  Ahmad Fattahi

                                  While I personally applaud Gregor's enthusiasm to provide world-class personal support, I tend to agree with Rick here. Let's be social

                                    • Re: Two Element Version Issues
                                      Rick Davin

                                      I also applaud Gregor's enthusiasm and willingness to see an issue resolved.

                                       

                                      Meanwhile, I've done a lot of thinking about the duplicate events and feel that its not a bug.  It is intentional and its the easiest, cleanest way to represent the data.  One of my biggest concerns with duplicate events was which one would be returned with a GetValue(@version boundary).  The good news is that the correct one from the effective version!   So the only issue is with data over a time range.

                                       

                                      To correctly represent values towards the end of a "version frame" and particularly between "version frames", you really do need an end value to get the correct stepping or interpolation.  Not all systems are 1-second systems, so simply ending 1-second earlier is not a sufficient solution.  Ending 1/65536th of a second earlier starts to get ugly and may not be sufficient.  So it's less messy and better for PB trending to have the end date as it is.

                                       

                                      This past week, I've dug pretty deep in element versions.  I have parents with versioned children.  I have versioned parents with versioned children.  I have other cases.  All in all, its a very powerful feature but it can get very messy very quick.

                                        • Re: Two Element Version Issues
                                          cmanhard

                                          Just getting back from UC and seeing this post.  Rick, I'm glad to hear that you came to the conclusion that this feature is intentional, because it is :)  The primary benefit of the behavior is it allows for better handling of mix of attribute configurations between pi points and non pipoints, which is something that could happen as a device goes in and out of service.