I had this url for photo searches on Wikimedia Commons :
https://commons.wikimedia.org/w/api.php?
action=query&
prop=imageinfo|categories&
generator=search&
gimlimit=10&
gsrsearch=File:"${title}"&
iiprop=extmetadata|url&
iiextmetadatafilter=ImageDescription|ObjectName&
gsrnamespace=6&
format=json&
origin=*
where ${title} is the search term. It was working beautifully. All of a sudden now it stopped working. I get this error:
Unrecognized parameter: gimlimit
I tried taking that parameter out and now nothing gets returned at all. This used to work. What has changed?
Parameter names look like ['g' for generator][module prefix][base parameter name]. So if you want to limit the number of search results, that would be gsrlimit. If you want to limit the number of image revisions to return info for per search result, that would be iilimit (it defaults to 1 though so you probably don't need to change it).
As you can see from your own link, you go get results (and removing gimlimit does not change anything, beyond the warning not showing up).
Related
On Wikipedia search box you can search for a term, e.g. 'lens', in article's title AND content. Using the search API however works only with titles. What request do I need to be able to extend the search on article content too?
The search API should perform "a full text search". The reason you're receiving only 10 results is most likely because you've not set the srlimit parameter which defaults to 10 and you're not continuing the query. You can set srlimit to max to receive 50 or 500 results (depends on the access level of your account) and in order to get the rest of the results one needs to continue the query using the parameters given in the last result.
I'm using Gerrit REST API to query all changes whose status is "merged". My query is
https://android-review.googlesource.com/changes/?q=status:merged&n=2
where "n=2" limits the size of query results to 2. So I got a JSON object like:
Of course there are more results. According to the REST document:
If the n query parameter is supplied and additional changes exist that match the query beyond the end, the last change object has a _more_changes: true JSON field set. Callers can resume a query with the N query parameter, supplying the last change’s _sortkey field as the value.
So I add the query parameter N with the _sortkey of the last change 100309. The new query is:
https://android-review.googlesource.com/changes/?q=status:merged&n=2&N=002e4203000187d5
With this new query, I was hoping that I'll get another 2 new query results, since I provided the _sortkey as a cursor of my previous search results.
However, it's really weird that this new query returns exactly the same results as the previous query, instead of the next 2 results as I expected. It seems like providing "N=002e4203000187d5" has no effect at all.
Does anybody know why using _sortkey to resume my query doesn't work?
I chatted with one of the developers at Google, and he confirmed that _sortkey has been removed from the newer versions of Gerrit they are running at android-review and gerrit-review. The N= parameter is no longer valid. The documentation will be updated to reflect this.
The alternative is to use &S=x to skip x results, which I tested and works well.
sortkey is deprecated in Gerrit v2.9 -
see the (Gerrit) ReleaseNotes-2.9.txt, under REST API - Changes:
[[sortkey-deprecation]]
Results returned by the [query changes] endpoint are now paginated using offsets instead of sortkeys.
The sortkey and sortkey_prev parameters on the endpoint are deprecated.
The results are now paginated using the --limit (-n) option to limit the number of results, and the -S option to set the start point.
Queries with sortkeys are still supported against old index versions, to enable online reindexing while clients have an older JS version.
See also here -
PSA: Removing the "sortkey" field from the gerrit-on-borg query interface:
...
Our solution is to kill the sortkey field and its related search operators (sortkey_before, sortkey_after, and resume_sortkey).
There are two ways you can achieve similar functionality.
Add "&S=" to your query to skip a fixed number of results.
(Note that this redoes the search so new results may have jumped ahead and
you might process the same change twice.
This is true of the resume_sortkey implementation as well,
so your code should already be able to handle this.)
Use the before/after operators.
Instead of taking the sortkey field from the last returned change and
using it in a resume_sortkey operator, you take the updated field from
the last returned change and use it in a before operator.
(This has slightly different semantics than the sortkey field, which
uses the change number as a tiebreaker when changes have similar updated times.)
...
I moved three files in My Drive to the trash. Then retrieved changes with Changes: list API (https://developers.google.com/drive/v2/reference/changes/list). It returned three changes, with ids 11607, 11608 and 11609. However, the largestChangeId field was 11608. When I made the API request again with startChangeId: 11608, it returned the two last changes. When I made the API request with startChangeId: 11609, it returned no result.
Is it expected? Or relying on change ids in such a way is not right?
In your case, it looks like you're exposed to a bug. I'm adding details of the changes list and how it should work in normal circumstances. Let's assume your latest change id was 11606 and you made three trashing operations.
GET changes?startChangeId=11607 should list:
11607
11608
11609
And the next time you are requesting changes.list, you should always increment the latest latestChangeId by 1.
In this case you need to request the following on your next poll.
GET changes?startChangeID=11610 and it will be returning an empty list.
First time implementing Full Text Search...
I've run the necessary ALTER TABLE SQL to enable FULLTEXT on the applicable tables/fields.
On the following beta site: http://wtc.betaforming.com/
If I do a search for "leadership", I get normal results except for the Events section at the bottom. I have Events with that word in the event title and throughout the description copy (http://wtc.betaforming.com/events/event/?event_id=10039).
If I do a search for "communications", I get results in the Events section, which makes me think I have everything configured correctly.
I'm using the following basic code for testing purposes:
SELECT *
FROM tblevents
WHERE MATCH(event_title, event_desc_long, event_desc_short, event_tab_one_title, event_tab_one_text, event_tab_two_title, event_tab_two_text, event_tab_three_title, event_tab_three_text, event_tab_four_title, event_tab_four_text) AGAINST ('$site_search_term')
This is the same code I'm using to search Products and Articles (changing the necessary FROM and WHERE information).
Not sure what is happening (since it works for some phrases) or where to start looking in my db to see what is wrong.
Thanks
Brett
The answer to my question can be found here:
http://dev.mysql.com/doc/refman/5.0/en/fulltext-natural-language.html
My search term was over the 50% threshold - you have to read all the way to the bottom to find this.
I've implemented the "IN BOOLEAN MODE" for my events search and everything appears to be working correctly. I also used this article for help:
http://devzone.zend.com/26/using-mysql-full-text-searching/
Using the Box 1.0 REST API, I am trying to work with the functions in SOAP UI.
The API doc for get_managed_users with user_id=12345 (internal id retrieved with get_user_id call correctly) is returning all the users. The docs say that would be the case if you do not specify a user_id value. But my full command is: (Token and API key changed to protect the clueless)
https://www.box.com/api/1.0/rest?user_id=27360&auth_token=blahbalhblah1234&action=get_managed_users&api_key=someKeyYouShouldNotSee
Now I could work with the complete result list, but that won't scale as we get thousands of users into the system.
I can make a call with edit_managed_user, using the same user_id value and the change is reflected in the UI, and in the next get_managed_users call. Thus I do have the correct user_id value, I would so assume.
I tried testuser#gmail.com as the user_id value as well, and get the entire list back. This leads me to believe that somehow I am sending user_id wrong, but I just do not see it.
Any hints? Why, with what seems like a valid user_id value is it acting like it is absent or incorrect?
Most likely you have either called this method with an invalid user_id, or one that is not in your set of managed users. Can you double check that the user comes back in your list of already managed users?