Selectors / too many HTTP requests?

[Geoff Hudik]

I get a story with: 

_versionOne.Get.PrimaryWorkitemByDisplayID()

Then I get child tasks with:

var filter = new SecondaryWorkitemFilter();

filter.Parent.Add(story);

filter.State.Add(State.Active);

EagerLoadSelectors.ToList().ForEach(s=> filter.Selectors.Add(s));

The problem is there are a ton of HTTP requests getting made, one for each of fields like Status, Source, ToDo, Description, Owners, DetailEstimate, etc.

I tried adding selectors such as below but it didn't appear to make much/any difference (also no documentation on using):

private static readonly HashSet<string> EagerLoadSelectors = new HashSet<string>

{

//"Category", // 'Unknown AttributeDefinition: Workitem.Category.' Also Category? Shows up in fiddler

"ChangeDateUTC",

"DetailEstimate",

"Description",

"Owners",

//"Source?", // 'Unknown AttributeDefinition: Workitem.Source'. Also Source, TaskSource

"ToDo"

};

See attached screenshot of Fiddler capturing requests. Currently it's taking up to 15 seconds or more to get a story and it's tasks. 

I understand the need to not fully load everything with requests, especially when querying multiple work items and with sub collections. But when getting a single work item and asking for basic fields like Status, etc. I wouldn't expect so many requests that are killing performance.

How can I eagerly load all the fields of a task at once or otherwise make this perform better?

[Acey Bunch]

Geoff,

The V1 .NET Object Model is notoriously non-performant for the reasons that you have discovered. In fact, VersionOne is in the process of sunsetting it.

If at all possible, I would suggest moving away from it and using something else. If you really want a wrapper to the HTTP calls, try using the .NET API Client.

However, for the best performance you should code the HTTP request/responses yourself using the query.v1 endpoint.

You can check that out here: http://community.versionone.com/Developers/Developer-Library/Recipes/Tour_of_query.v1

Hope that helps...

-Acey

[Geoff Hudik]

We are using the .net API client unless you're referring to another one. These nuget packages:

<package id="VersionOne.SDK.APIClient" version="14.1.1.290" targetFramework="net451" />

<package id="VersionOne.SDK.ObjectModel" version="14.1.1.923" targetFramework="net451" />

I didn't realize that API was being deprecated or the other one existed. I just finished a good bit of code against the old but I'll take a look at the new API.

Thanks

[Geoff Hudik]

One more question - will the old API continue to work for some time and if so, how long? Or will it just not be supported as far as issues/questions but continue to function?

[Acey Bunch]

Sunset of the OM was announced in the Spring 2014 release, so it will continue to be supported for 1 year from then. However, no new development will be done on it.

Here's the link to the sunset announcement: http://community.versionone.com/Release-Notes-and-Downloads/Spring_2014_Release_Notes

On Monday, September 29, 2014 2:35:10 PM UTC-4, Geoff Hudik wrote:

[Murphy, Sheila]

So, the link you sent says:

The forthcoming sunset status is noted on the detail page for a sunset libraries. Where possible, we will offer go-forward options.

 

Where can one find the “detail page” for the “Object Model Libraries”?

 

Sheila

--
You received this message because you are subscribed to the Google Groups "VersionOne-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to versionone-de...@googlegroups.com.
To post to this group, send email to version...@googlegroups.com.
Visit this group at http://groups.google.com/group/versionone-dev.
For more options, visit https://groups.google.com/d/optout.

[Ian Buchanan]

Sheila,

You'll probably find this explanation a bit circular. The statement about the detail page was an oversight. There is no page for the .NET Object Model libraries. I suspect you were looking for the go-forward options but those have already been mentioned. For reporting we recommend using the query.v1 endpoint with simple HTTP and JSON libraries in .NET. There is also the API Client as a wrapper but, for reporting uses, developers sometimes consider this library too verbose.

To elaborate about deprecation, the Object Model had a fundamental design flaw that you observed. When you navigate relationships (as one does with an OO program) and get data from those relationships, then you incur network calls that you cannot control. The flaw was "abstracting" the network calls into simple getters. While convenient, it hides expensive HTTP requests behind typical method calls. Over time, we had observed the leading cause of API abuse in VersionOne were the very libraries we were providing to developers. We closely examined the Object Model libraries a number of times in an attempt to "refactor" the problem out. Unfortunately, we came to the same conclusion each time -- any improvement would come at the cost of breaking changes. In which case, we might as well offer a completely new approach. Hence, we developed query.v1 as a simpler endpoint that could be used with standard libraries so you don't need a special SDK.

We do apologize for any efforts that you might have sunk into the Object Model but we are confident the query.v1 endpoint will be easy to use and performs well.

Yours truly,

Ian Buchanan

Product Manager for Platform and Integrations

To post to this group, send email to versio...@googlegroups.com.