Confused with lookback api compress option

[Inna Shulman]

Hi,

I'm trying to use lookback api and don't seem to get it.

Here is the query:

{
"find": {
"_ProjectHierarchy": <reducted>,
"_TypeHierarchy": "HierarchicalRequirement",
"FormattedID" : "SC6920",
"_ValidFrom": { "$gte": "2020-05-11"
}
},

"fields": ["FormattedID", "ScheduleState"],
"hydrate": ["ScheduleState"],
"compress": true,
"start": 1,
"pagesize": 200

}

The item has total 16 revisions and this query brings

    "TotalResultCount": 12,

    "HasMore": false,

    "StartIndex": 1,

    "PageSize": 200,

    "ETLDate": "2020-05-12T16:04:45.107Z",

    "CompressedResultCount": 11,

There is only one revision where the ScheduleState has changed, all the others did not affect it. And yet the results set contains 11 items and all of them have the same ScheduleState value.

What am I doing wrong?

Thank you,
Inna

[Sagi Gabay]

Hi Inna,

I don't think you're doing anything wrong. However, check out this documentation page about LBAPI, specifically see the "Compressing Snapshots" section. It does mention:

Note:

• When using compression, _ValidFrom, _ValidTo, and ObjectID must be included in the fields.
• The response now includes CompressedResultCount. This is the total number of compressed snapshots returned. To determine the amount of compression, compare this value with the TotalResultCount.

I see you're list of fields doesn't include _ValidFrom and _ValidTo - so you probably want to correct that.
Also, the second point seem to suggest that your results are okay where your compressedResultCount is 11, while the Total is 12, leaving you with just 1 snapshot of actual value.

I'd start by including _ValidFrom and _ValidTo to your fields, see if that makes a difference, however, I feel it wont make a difference and also that your results are the expected ones. Please let us know.  I can go to Engineering to learn more on this if you'd like. Let's see if these two fields will make a difference first though.

Thanks,
Sagi

[Inna Shulman]

Hi Sagi!

Thanks for looking into it.

I've tried adding these two fields and it did not make any difference. 
But adding the ObjectID did result in a single entry that corresponds to the only revision in the history of this object that mentioned change made to ScheduleState!

So adding all 3 fields does result in correct output, while leaving out any of them brings extra.

Thank you very much!
Inna

[Sagi Gabay]

Nice! Good job.

Thanks much Inna. I'll check with Engineering and if indeed ObjectID needs to also be included then I'll ask to change the documentation to include it.

Thanks again, glad it worked out.
Sagi