Repository navigation
multiple where clauses and closure issue #4
Description
Hi,
I have been playing around with the VersionOne JS SDK for node and have a few questions. I based my code on the sample.js file provided with the SDK.
What I'm trying to achieve is a query for Backlog Items where Status.Name is 'Prepared' and Scope.Name is 'My Project'
So I tried this:
v1.query({
from: "Story",
where: {
"Status.Name": "Prepared",
"Scope.Name": "My Project"
} // etc.
But that doesn't return any results, if I take out the "Status.Name" or "Scope.Name" property then I get results, I can filter out results based on the property values after they have been returned but it seems it doesn't work when I pass the two values in the 'where' clause. Am I doing something wrong here or is this expected behavior?
Also, I think there may be a defect in the v1meta.js file (or more correctly in the v1meta.coffee file). My 'success' function is being passed the same result object for every invocation. I believe it's down to the following loop in the V1Meta.prototype.query method:
for (_i = 0, _len = _ref.length; _i < _len; _i++) {
assetxml = _ref[_i];
oidtoken = assetxml.get('id');
_ref1 = oidtoken.split(':'), found_type = _ref1[0], found_id = _ref1[1];
_results.push(_this.get_asset_class(found_type, function(err, Cls) {
var asset;
if (err != null) {
return options.error(err);
}
asset = _this.build_asset(Cls, assetxml);
return options.success(asset);
}));
}
The assetxml value is being overwritten everytime the loop iterates, but before the get_asset_class callback is called. Closing over the assetxml variable within the loop resolves it though
(function(thisAsset) {
_results.push(_this.get_asset_class(found_type, function(err, Cls) {
var asset;
if (err != null) {
return options.error(err);
}
asset = _this.build_asset(Cls, thisAsset);
return options.success(asset);
}));
})(assetxml);
I'm not really familiar enough with coffee script to make any useful contributions however.
I think it would also be useful to pass all the results to the success method rather than each result individually. Or perhaps if all results are passed to a done method instead.
Thanks!
Peter
Activity
JogoShugh commentedon Dec 6, 2013
Peter, thanks for the debugging and ideas! It can be tricky to get closures right in CoffeeScript. We will check that out today or Monday and see if we can get that fixed up.
Thanks again for the interest in this and submitting such a detailed report.
JogoShugh commentedon Dec 6, 2013
Hey Peter, I'm not sure if you plan to modify data or not. If you only need to query for data, you might be interested in a newer endpoint we created called query.v1:
http://community.versionone.com/Developers/Developer-Library/Recipes/Tour_of_query.v1
http://community.versionone.com/Developers/Developer-Library/Documentation/API/Endpoints/query.v1
Using query.v1 you will get back pure JSON results, and it can accept either JSON or YAML formatted queries.
PerterB commentedon Dec 9, 2013
Yes, I do plan on modifying data eventually. I don't think I'll be able to use query.v1 since we're on an older version (12.1 I think), in fact that might be why I can't query using multiple where clauses...
jamesjenner commentedon Aug 25, 2014
Hmm. Just realised that this issue is multiple issues. I stopped reading the first time when I saw the multiple selection criteria problem. So I've created a new issue about the closure problem.
Is there any update on when this will be resolved?
jamesjenner commentedon Aug 26, 2014
I've found the cause of the multiple where problem. It's in the generated
client.js, functionV1Server.prototype.get_query_xml.The problem is the anonymous function as the input to the push for
wherestrs. The function returns an array, however thearray.prototype.push()doesn't support an array. I suspect it is converting it to a string which includes the comma delimiter for the string.To solve the problem all you need to do is change
to
Also change the end of the function from:
to
Of note is the issue of how to determine the logical operand for each where statement. It forces use of and for example:
Is converted to:
To get around this I found a hidden option. If
whereis not defined then the code is checking forwherestr. It will set the where condition to the value of thewherestr. so in theory the above could be modified to the following:This appears to allow changing the logical condition.
I hope the above helps anyone coming across this.