I need to export all rules by language. I can get a set of 100 rules from the web API for a given language, but it seems the web API is limited to paging through the rules 100 rules at a time. Obviously I can set the pagesize higher (i.e. 500) but what about rule sets that have more than 500 rules (i.e. Java)? Do I need to page through the rules until the end? How do I tell when I have the last page?
Try and see: https://sonarqube.com/api/rules/search?languages=java,js , returns the list of rules for Java and JavaScript . Response starts by:
{
"total": 537,
"p": 1,
"ps": 100,
"rules": [...] // 100 items
}
The rest of it is just good ol' maths: 537 items in total, page sizes of 100. So, all things considered, page 6 should be the last one: https://sonarqube.com/api/rules/search?languages=java,js&p=6 - 37 rules returned, job is done (and incrementing further p would anyhow only give you an empty JSON back.
Related
I am using Solr 7.6. While performing a search query, Solr gives a wrong version field of a document but all the other fields are correct.
In Solr dashboard the query gives the following result:
{
"id":"518fce46-3617-4380-aaf6-8f6d36e08e6a",
"type":"tag",
"count":1,
"_version_":1626999925241806848
}
Whereas, solr-node search function gives:
{
"id": "518fce46-3617-4380-aaf6-8f6d36e08e6a",
"type": "tag",
"count": 1,
"_version_": 1626999925241806800
}
Initial guess is that the solr-node module returns the value as a double (instead of as a string), and the precision of a double isn't good enough to represent the value 1626999925241806848 exactly.
We can confirm this directly in our browser's console:
-> 1626999925241806848
<- 1626999925241806800
i.e. if we input the numeric value 1626999925241806848, it'll be represented by the floating point number that's closest, and that's 1626999925241806800.
solr-node should probably return these values as a string when they exceed the representable value for ints.
Update: solr-node details this at their overview page:
Use json-bigint to handle correctly numbers too large for Javascript Number such as the values of the fields *l and _version. By default json-bigint library is not used because the performance difference compared to the native JSON library is too important with "large" chunk of JSON (https://github.com/lbdremy/solr-node-client/issues/114#issuecomment-54165595), but you want to enable it if you use the Optimistic Concurreny feature available in Solr 4.x, along with RealTime Get and Atomic Updates features because they use the version field. In order to enable it do var client = solr.createClient({ bigint : true}) or directly on the client instance client.options.bigint = true.
What is the official way to find documents that match NaN in an Edm.Double field via the rest API on version 2016-09-01-Preview and above?
Specifically we see this json post to the /search endpoint finds the document in version 2016-09-01, but not in version 2016-09-01-Preview and above.
{"filter":"(doublefield eq NaN)","select":"id","top":10,"skip":0,"count":true}
Full reproduction information below
Index definition:
{
"name":"indexnamehere",
"fields":[
{
"name":"doublefield",
"type":"Edm.Double",
"searchable":false,
"filterable":true,
"sortable":true,
"facetable":false,
"key":false,
"retrievable":true
},
{
"name":"id",
"type":"Edm.String",
"searchable":false,
"filterable":true,
"sortable":true,
"facetable":false,
"key":true,
"retrievable":true
}
]
}
Documents:
{
"value":[
{
"id":"60660cd3b9e24d26ae3609926f44aead",
"doublefield":"NaN",
"#search.action":"upload"
},
{
"id":"70660cd3b9e24d26ae3609926f44aead",
"doublefield":"2",
"#search.action":"upload"
}
]
}
Query 1 - finds the document:
{"filter":"(doublefield eq 2)","select":"id","top":10,"skip":0,"count":true}
Query 2 - fails to find the document (in 2016-09-01-Preview and above):
{"filter":"(doublefield eq NaN)","select":"id","top":10,"skip":0,"count":true}
ps. this is our current work around not(doubleField ge -INF) and doubleField ne null
Starting with API version 2016-09-01-Preview, Azure Search now implements the IEEE 754 semantics for comparisons with NaN, per the clarified OData V4.01 specification.
The special value NaN is not equal to anything, even to itself.
Prior to this, NaN comparisons were unreliable. In particular, the inequality operators did not behave correctly, or even consistently between different Search services.
We made this change on an API version boundary to avoid breaking existing applications, but going forward applications using version 2016-09-01-Preview or later cannot detect NaN in double fields. If you need to have some kind of sentinel value for Edm.Double fields, we recommend using null instead since you can check for null with filters.
Allowing NaN to be indexed has turned out to be problematic, and we're considering disallowing it altogether in a future API version.
Per the API documentation, manipulating the vales of "start" and "end" will result in different data sets being returned. Strangely, changing the values of start and end resulted in the same result being returned. What am I missing? Thanks!
qopts = {'query': '/automotive and vehicles',
'aggregation' : '[term(yyymmdd).term(docSentiment.type,count:3)]',
'return': 'docSentiment.type,yyyymmdd',
'count': '50',
'start': 'now-2w',
'end' : 'now-1w',
'offset': my_offset}
my_query = discovery.query(my_disc_environment_id, my_disc_collection_id, qopts)
I hope it is helpful for you.
I am not sure if this is right answer for you because I have limited information.
First of all, please check the number of return-sets. if the return-set has more then 50 dataset, result could be same. (might count param. -1 = unlimited in the rest API of WCA (Watson Context Analytics)
Second, if you can check the log from the server side, you can see the full query which manipulated from WATSON engine.
Last, I am not really sure that watson REST-API can recognize 'now-2w' style start-end form. Would you please link the tutorial? In my previous project, I wrote the start-end date by Y-M-D form.
Good Luck
Using ng-pluralize with this template:
Your subscription <span ng-pluralize count="::vm.account.subscription.expirationDays"
when="{ '-1': 'has expired!',
'0': 'expires today!',
'one': 'expires tomorrow.',
'other': 'expires in {} days.'}"></span>
Yields the following result:
Expiration Days Label
-1 Your subscription has expired!
0 Your subscription expires today!
1 Your subscription expires tomorrow!
X Your subscription expires in X days.
However, this breaks as soon as a subscription expires 2 days ago.
Is it possible to define a boolean expression as a when clause so that
vm.account.subscription.expirationDays < 0 === 'has expired!'
Currently I'm having to handle expired labels in a different element which kind of defeats the purpose of using ng-pluralize.
It looks like your scenario is, albeit perhaps a common one, too complex for ngPluralize. I also doubt it will change, because ngPluralize is based on "plural categories":
http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html
The problem being that en-US, Angular's default locale, defines only the categories "one" and "other". Anything that doesn't fall into those categories is explicitly defined (or inferred by $locale.pluralCat).
The three best options for your scenario that immediately come to me are:
1) Simplest would be to have two objects:
when="count >=0 ? positivePlurals : negativePlurals"
where, of course $scope.count = vm.account.subscription.expirationDays, positivePlurals is your positive phrases and negativePlurals is your negative phrases.
2) Wrap a localization library that supports many-or-custom plural rules (such as i18next) in a directive, and use that instead. I'm not very familiar with the popular angular-translate, but at first glance it doesn't seem to support custom pluralization rules. It does, however, allow logic in interpolation, so you might get away with that.
3) Write a directive similar to ngPluralize that supports ("-other", "x", "other"). The source for ngPluralize is available here. It would probably be as simple as modifying the statement at L211 in a way similar to:
var countIsNaN = isNaN(count);
var countIsNegative = count < 0;
if (!countIsNaN && !(count in whens)) {
// If an explicit number rule such as 1, 2, 3... is defined, just use it.
// Otherwise, check it against pluralization rules in $locale service.
count = $locale.pluralCat(count - offset);
if(countIsNegative){
count = '-'+count; // "-one", "-other"
}
}
I'm trying to run a query and sorting by a date field.
q = self.request.get("q")
index = search.Index(name="transaction")
sort_options = search.SortOptions(
expressions=[
search.SortExpression(expression='timestamp_date', direction=search.SortExpression.DESCENDING)
],
limit=1000)
options = search.QueryOptions(limit=30, cursor=search.Cursor(), sort_options=sort_options)
results = index.search(search.Query(query_string=q, options=options))
On the development server, the code works but the results are not correctly sorted. On the production server it doesn't work at all; It gives the following error:
Search failed
Traceback (most recent call last):
File "/base/data/home/apps/s~xxx/pre-24.359846149527858049/main.py", line 78, in get
results = index.search(search.Query(query_string=q, options=options))
File "/base/python27_runtime/python27_lib/versions/1/google/appengine/api/search/search.py", line 2609, in search
_CheckStatus(response.status())
File "/base/python27_runtime/python27_lib/versions/1/google/appengine/api/search/search.py", line 414, in _CheckStatus
raise _ERROR_MAP[status.code()](status.error_detail())
TransientError
I'm wondering how to make it work on the production server and how to sort correctly on the development server. I know its experimental technology, but I wanted to check to see if this was something I was overlooking
You need to provide a default value for all SortExpressions. This will be made clear in a forthcoming release. Also there is no explicit support for default Date values yet, so you need to put a default numeric value representing the number of days since 1970-01-01. In the code below, I am using the date 1970-01-01 as the default by specifying a value of 0.
sort_options = search.SortOptions(
expressions=[
search.SortExpression(expression='timestamp_date', default_value=0)
])
Also note that you do not need to specify direction=search.SortExpression.DESCENDING as that
is the default for direction. You do not need to specify the default value of 1000 for the limit either.