From: http://developers.soundcloud.com/docs/api/tracks#filtering
I'm not sure from the docs if this functionality is available. I want to be able to:
use a range filter for comment_count, download_count, playback_count, favoritings_count, e.g. favoritings_count[from]=100
Is there a way I can use a range filter on # of favoritings with the current API?
I also see there are filters for "genres" and "types", but no examples are given. How do I use these filters?
The tracks resource does not currently support filtering on any of the properties you mentioned. You can apply interval filters to bpm, duration and created_at. You can however, set the 'order' param to 'hotness'. A tracks 'hotness' is determined by a number of factors, including the number of favoritings.
Genre is a user defined field, and therefore there isn't a strict enumeration of valid values. Common ones are things like 'dubstep' or 'house' or 'punk', etc. Types is currently one of: other, sample, sound effect, loop, stem, in progress, demo, podcast, spoken, recording, live, remix, original. Note that these are subject to change in the future.
I'll look into adding a list of valid values for 'types' to the docs. Thanks for pointing that out.
Related
I have an influxdb instance, in which an upstream server is logging measurements into. I have multiple series of the shape: web.[domain].[status], for example: web.www.foobar.com.2xx, web.www.quux.com.3xx etc. There are two "variables" encoded into the series name: the domain and the status (2xx, 3xx, etc. are already aggregated).
Now I'd like to see how many of those requests I get. One possibility would be to just list the series:
select sum("value") from "web.www.quux.com.2xx","web.www.quux.com.3xx",...
But this is neither practical (too many) nor actually feasible (new domains are added and removed all the time), so I need a more flexible approach.
Is there some kind of wildcard syntax allowed in the from clause? The documentation doesn't mention any. Or is there another way to approach this?
You should to avoid this kind of measurement naming convention:
https://docs.influxdata.com/influxdb/v1.8/concepts/schema_and_data_layout/#avoid-encoding-data-in-measurement-names
hAvoid encoding data in measurement names
InfluxDB queries merge data that falls within the same measurement; it’s better to differentiate data with tags than with detailed measurement names. If you encode data in a measurement name, you must use a regular expression to query the data, making some queries more complicated or impossible.
I have a large databases of objects where I'd like to show objects that are nearer to the user searching first so I'm using aroundLatLngViaIP.
This works well for objects that are near by, however, if there aren't any nearby it doesn't show any further away even if there is an exact text match.
Is it possible to use aroundLatLngViaIP to promote results nearby but not exclude those that are far away?
To achieve this, you need to use aroundRadius: all as an additional query parameter. Quoting from the doc:
The special value all causes the geo distance to be computed and taken into account for ranking, but without filtering; this option is faster than specifying a high integer value.
https://www.algolia.com/doc/api-reference/api-parameters/aroundRadius/
I am using the Bing Web Search provided by Microsofts Cognitive Services API suite.
I would like to make a single query that returns the top results from all markets. Essentially, I'm looking for something like this:
https://api.cognitive.microsoft.com/bing/v5.0/search?q=search_term&count=5&mkt=all
This would return the top 5 results from all available markets.
Is there a way to achieve this or would I need to query all markets individually.
Thanks!
Interesting question, no finite answers in the documentation.
If you read below, using cc, you can supply multiple values. However it's using the first, suggesting supplying multiple does not trigger different behavior.
Then later suggesting it's possible to do an aggregated market.
cc - If you set this parameter, you must also specify the Accept-Language header. Bing uses the first supported language it finds in the specified languages and combines it with the country code to determine the market to return results for. If the languages list does not include a supported language, Bing finds the closest language and market that supports the request. Or, Bing may use an aggregated or default market for the results.
Again, this is using cc and Accept-Language header, instead of mkt and setLang.
Since the former can be called with multiple values, contrary to the latter.
I'm currently struggling at a complex URL handling concept question. The application have a product property database table/collection with all the different product types (i.e. categories, colors, manufacturers, materials, etc.).
{_id:1,alias:"mercedes-benz",type:"brand"},
{_id:2,alias:"suv-cars",type:"category"},
{_id:3,alias:"cars",type:"category"},
{_id:4,alias:"toyota",type:"manufacturer"},
{_id:5,alias:"red",type:"color"},
{_id:6,alias:"yellow",type:"color"},
{_id:7,alias:"bmw",type:"manufacturer"},
{_id:8,alias:"leather",type:"material"}
...
Now the mission is to handle URL requests in the style below in every(!) possible order to retrieve the included product properties. The only allowed character is the dash (settled SEO requirement, some properties also can include dashes by themselve - i think also an important point - i.e. the category "suv-cars" or the manufacturer "mercedes-benz"):
http:\\www.example.com\{category}-{color}-{manufacturer}-{material}
http:\\www.example.com\{color}-{manufacturer}
http:\\www.example.com\{color}-{category}-{material}-{manufacturer}
http:\\www.example.com\{category}-{color}-nonexistingproperty-{manufacturer}
http:\\www.example.com\{color}-{category}-{manufacturer}
http:\\www.example.com\{manufacturer}
http:\\www.example.com\{manufacturer}-{category}-{color}-{material}
http:\\www.example.com\{category}
http:\\www.example.com\{manufacturer}-nonexistingproperty-{category}-{color}-{material}
http:\\www.example.com\{color}-crap-{manufacturer}
...
...so: every order of the properties should be allowed! The result have to be the information about the used properties per URL-Request (BTW yes, the duplicate content will be fixed by redirects and a predefined schema). The "nonexistingproperties"/"crap" are possible and just should be ignored.
UPDATE:
Idea 1: One way i'm thinking about the question is to split the query string by dashes and analyze them value by value, the problem: At the two or three or more word combinations at some properties there are too many different combinations and variations so a loooot of queries which kills this idea i think..
Idea 2: The other way is to build a (in my opinion) too large Alias/URL-Table with all of the different combinations, but i think that's just an ugly workaround. There are about 15.000 of different properties so the count of the aliases in the different sort orders is killing this idea.
Idea 3: It's your turn! Thanks for your mind and your time.
While your question is a bit broad, below are some ideas. There isn't a single awesome answer unless you find a free or commercial engine for this that works exactly the way you want.
The way I thought about your problem was to consider the URL as a list of keywords.
use Lucene as a keyword/tag system. It's good at the types of searches you suggest you want, including phrases, stems, etc.
store and index the data in DB of choice, but pull the keywords into memory and build a bit index of all keywords vs items. Iterate through the keyword table producing weighted results. If order of keywords matters, you'll also need make a pass through the result set to weight based on word order. These types of searches always need to cap their result set quickly in order to return results quickly.
cache the results like crazy from working matches, and give precedence to results that users seem to click on the most for a given URL.
attack the database by using tag indexes in MongoDB. You'd still need to merge and weight results. Very intensive and not likely a good use of DB resources.
read some of the academic papers on keyword searches. It's a popular topic.
build a table of words that have dashes in them, and normalize/convert those before running your queries
always check for full exact matches first
The only way this may work, if you restrict all property values to be unique. So, you make a set of categories+colors+manufacturers, etc. All values have to be unique. This will allow you to find to what property the value belongs.
The data structure for this should be fairly simple:
{_id:ValueOfTheProperty, Property:TypeOfProperty}
Here are some possible samples:
{ _id: Red, Property: Color }
{ _id: Green, Property: Color }
{ _id: Boots, Property: Category }
{ _id: Shoes, Property: Category }
...
This way, the order does not matter, and you are able to convert them in a single pass to a map:
{ Color: Red, Category: Boots }
Though, I predict some problems with ambigous names here.
I'm trying to create a more advanced query mechanism for REST. Assume I have the following:
GET /data/users
and it returns a list of users. Then to filter the users returned for example I'd say:
GET /data/users?age=30
to get a list of 30 year old users. Now lets say I want users aged 30 - 40. I'd like to have essentially a set of reusable operators such as:
GET /data/users?greaterThan(age)=30&lessThan(age)=40
The greaterThan and lessThan would be reusable on other numeric, date, etc fields. This would also allow me to add other operators (contains, starts with, ends with, etc). I'm a REST noob so I'm not sure if this violates any of the core principles REST follows. Any thoughts?
Alternately, you might simply be better off with optional parameters "minAge" and "maxAge".
Alternative 2: encode the value(s) for parameters to indicate the test to be performed: inequalities, pattern matching etc.
This gets messy no matter what you do for complex boolean expressions. At some point, you almost want to make a document format for the query description itself, but it's hard to think of it as a "GET" anymore.
I would look into setting the value of the query parameter to include syntax for operators and such .. something like this for a range of values
/data/users?age=[30,40]
or
/data/users?age=>30&age=<40
would make it a little easier to read, just make sure to url encode if you are using any reserved characters