I have an app that (among other things) uses Yahoo Weather API to display weather conditions for a location selected by user.
In the configuration dialog where user can enter the location, I'd love to offer autocompletion so that while user is typing location name, list of matching cities is suggested.
I can use YQL to fetch locations matching the prefix, i.e.:
select * from geo.places where text = 'Vie*'
but the problem is that not every location has a weather station associated with it and I'd love to skip these in my autocompletion list.
Using community tables (table called weather.woeid), following query will join previous query with the weather api, returning only locations that do have weather stations:
select location from weather.woeid where w in (select woeid from geo.places where text = 'Vie*')
This almost solves my problem, except for the fact that previous query (which produces same result as weather api call) doesn't return WOEID nor any kind of identifier I can use to directly query the Weather API after configuration. How can I capture the value of join parameter w? I tried something like select w, location ... but that doesn't seem to work.
Is there any other way to get list of locations (incl. WOEID) matching certain prefix that have weather data associated with them?
Afaik it is not possible with YQL to pass through values from the Sub-Select (the inner SELECT statement) to the outer SELECT, which I is what you want to do if I understand you correctly.
Based on your use case I want to propose another solution though:
I assume that the list of locations that have a weather station associated with them is relatively static, meaning this list does not change very often. If that is the case then it would not be very optimal in terms of performance to regenerate that list every time with YQL. Instead I would generate that list offline, store it in a file or MySQL or elsewhere and then just use that static list to answer to the AJAX call of your autocomplete field.
The data in that static list could look something like this:
{
"Vienna" => 72342,
"Hamburg" => 12334,
...
}
Once the user has selected a location and pressed enter, then you can send the YQL query to weather.woeid to look up the current weather based on the WOEID.
Related
Is there any common URL to navigate to serviceNow portal with number (INC/REQ/CHG)?
I have an common URL (INC/REQ/CHG) which can be navigated to ServiceNow portal by sys_id:
https://XXXXdev.service-now.com/nav_to.do?uri=task.do?sys_id=XXXXXXXXXXXXXXXXXXXXX
I have tried below URLs for incident but it is creating a new record
XXXXdev.service-now.com/nav_to.do?uri=incident.do?sysparm_order=INC0XXX
OR
XXXXdev.service-now.com/nav_to.do?uri=incident.do?number=INC00XXXX
No problem if there are different URLs for INC, REQ or CHG, I want a URL to see record by giving a number but not with sys_id.
From what you have described I believe you want:
https://[instance].service-now.com/incident.do?sysparm_query=number=INC1234567
https://[instance].service-now.com/sc_request.do?sysparm_query=number=REQ1234567
https://[instance].service-now.com/change_request.do?sysparm_query=number=CHG1234567
Or the catch all
https://[instance].service-now.com/task.do?sysparm_query=number=INC1234567
https://[instance].service-now.com/task.do?sysparm_query=number=REQ1234567
https://[instance].service-now.com/task.do?sysparm_query=number=CHG1234567
(see https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/use/navigation/concept/c_NavigatingByURL.html)
If you want to keep the outer frames of SN then use the nav_to.do?uri= version e.g.
https://[instance].service-now.com/nav_to.do?uri=sc_request.do?sysparm_query=number=REQ1234567
which is what #kirk has described.
You have a couple of options depending on what you're trying to do exactly.
Email
If you're trying to send this link in an email notification, you can use ${URI_REF} for the table that the notification is generated on.
This will automatically generate a link to the record.
You can also dot walk to another table, for example
Catalog Task up to the Requested Item ${request_item.URI_REF}
Current task up top the parent record ${parent.URI_REF}
Calculated
If you are looking to generate this based on some calculated method you can do this with the table name and the record number.
https://instance.service-now.com/nav_to.do?uri=/table_name.do?sysparm_query=number=RECORD_NUMBER
For instance for a Change record with record number CHG0000123
https://instance.service-now.com/nav_to.do?uri=/change.do?sysparm_query=number=CHG0000123
You may also reference a record by using a parent table, though this is more for an interesting note rather than a good practice. INC, REQ, and CHG all inherit from the Task table so you could do this.
https://instance.service-now.com/nav_to.do?uri=/task.do?sysparm_query=number=CHG0000123
The drawback to using the parent table is that it won't have all fields and won't have the proper form layout. Mostly just an interesting exercise.
You may also leverage the text search and the system will pull up a record that matches the record number.
https://instance.service-now.com/nav_to.do?uri=/textsearch.do?sysparm_query=number=CHG0000123
Note that this works out of the box and you could have configured search to not behave that way.
Business Rule
Another method inside of a Business Rule is to use the current.getLink() method. This will return a URL to the record. If you would like to add to a journal entry, you could use this
var currentLink = "[code]<a href='" + current.getLink() + "'>" + current.number + "</a>[/code]";
var journal = gs.getMessage("The new record is {0}", [currentLink]);
gr.work_notes = journalEntry;
Your initial URI will actually work with a NUMBER (like INC000001), assuming that number is actually the display field for the table (as it is by default):
https://XXXX.service-now.com/incident.do?sys_id=NUMBER
When you do a sys_id= lookup, we first lookup by the sys_id column. If it's not found there, we try a lookup on the display value (number), which will load the form exactly as you expect.
{yourinstance}.service-now.com/nav_to.do?uri=incident.do?sys_id={incidentNumber}
Replace incidentNumber with your incident number .
I'm new to Elasticsearch and I need to execute a complex query, but I need some help.
Here is my use case:
I would like to recommend a new place to each of my users everyday.
However:
The place must be opened this week day
The chosen place must be near of the user (closer places have higher score)
The place should not be one of the last 10 places a user have already been/suggested (if a place has already been visited by a user in his last 10 visits, this place should have a lower score)
My first guess is to have 2 documents types as follow:
user_history
user_id
place_id
date
place
place_id
opening_days (array with week days the place opens)
location geo position of the place
Given a user with position [lat, lon] and id user_1, what could be the search query to execute to retrieve X places sorted by score? (better score is near of user and not in the 10 last places a user have already been).
This query seems to be a basic but I can't figure out how to "mix" data from user_history and from place to get places I want.
But that's not all!
With this query, if I want to attribute to each user a place I need 3 steps:
retrieve all users (with their position)
for each user, search for the best place
once I have this place, add it to the user_history
This seems very time consuming task. Is it possible to simplify it with less Elasticsearch queries?
For instance, having something like this:
retrieving for each user his best place (with 1 query, search for all users and find them the best place)
add the place to the history
Or event better:
retrieving for each user his best place and add it to the history (with 1 query, perform all the 3 tasks above)
I don't know if it's possible to create queries that complex. That's why I need your help to tell me if it's possible and how it could be accomplished.
I need to do this:
Sysyem ( web page ) ask a smartphone model to an user
User specify it in a form
System query some external page and with xpath extract what needed
System returns the cheapest item found ( if any ) with some xpath query on the external page, showing image, price, name, and giving the link to the original page
Now the problem is: if i order the results for descending price and i take the first, it's not the cheapest ( and sometime is not even the model i was looking for ), and if i take the last maybe will be not a smartphone, but a gadget like flip cover or other stuff.
I tought to use the xpath contains() to check if the name given at beginning by the user is present in the xpath query return value, but i found contains() is case sensitive, and is not so easy to make it case insensitive.
Here you can find an example of the issues described above: i query for "note 4", order by price, and both first and last can't be taken.
Actually i use php to load and make query on desired page, and i can easilly extract all i need ( for example first, last or just another random block of items from the required page ) but i need some method to take exactly the cheapest and right model the user is looking for from all that noisy results.
Some other ideas?
My app has a class that saves picture that users upload. Each object in the class has a city property that holds the name of the city that the picture was taken at, and a like property that tracks the number of likes.
I want to be able to send a query that returns one picture per city and each picture should have the highest ranking of likes in the city it belongs to. How can I do that?
One way which I first thought about is doing multiple queries by fetching the most liked picture of a city and save it in an array, and then do the same to other cities.
However, each country has more than one city, thus it's not that efficient.
Parse doesn't support the ordinary operations used in databases. Besides, I tried to use a compound query. Unfortunately, I can't set limit or ordering on the subqueries. Any good solution for this?
It would be easy using group by. Unfortunately, Parse does not support "select distinct" or "group by" features.
As you've suggested you need to fetch for each country all the cities, and for each one get the top most rated photo.
BUT, since Parse has strict restrictions on the duration time execution of a request ( 3 sec for an event listener, 7 sec for a custom function ), I suggest you to do this in a background job, saving in a new table the top rated photo for each city. In this way you can easily query the db from client. The Background jobs can be executed up to 15 minuted before parse drop them, so you could make that kind of queries without timeouts.
Hope it helps
Suppose I have a large (300-500k) collection of text documents stored in the relational database. Each document can belong to one or more (up to six) categories. I need users to be able to randomly select documents in a specific category so that a single entity is never repeated, much like how StumbleUpon works.
I don't really see a way I could implement this using slow NOT IN queries with large amount of users and documents, so I figured I might need to implement some custom data structure for this purpose. Perhaps there is already a paper describing some algorithm that might be adapted to my needs?
Currently I'm considering the following approach:
Read all the entries from the database
Create a linked list based index for each category from the IDs of documents belonging to the this category. Shuffle it
Create a Bloom Filter containing all of the entries viewed by a particular user
Traverse the index using the iterator, randomly select items using Bloom Filter to pick not viewed items.
If you track via a table what entries that the user has seen... try this. And I'm going to use mysql because that's the quickest example I can think of but the gist should be clear.
On a link being 'used'...
insert into viewed (userid, url_id) values ("jj", 123)
On looking for a link...
select p.url_id
from pages p left join viewed v on v.url_id = p.url_id
where v.url_id is null
order by rand()
limit 1
This causes the database to go ahead and do a 1 for 1 join, and your limiting your query to return only one entry that the user has not seen yet.
Just a suggestion.
Edit: It is possible to make this one operation but there's no guarantee that the url will be passed successfully to the user.
It depend on how users get it's random entries.
Option 1:
A user is paging some entities and stop after couple of them. for example the user see the current random entity and then moving to the next one, read it and continue it couple of times and that's it.
in the next time this user (or another) get an entity from this category the entities that already viewed is clear and you can return an already viewed entity.
in that option I would recommend save a (hash) set of already viewed entities id and every time user ask for a random entity- randomally choose it from the DB and check if not already in the set.
because the set is so small and your data is so big, the chance that you get an already viewed id is so small, that it will take O(1) most of the time.
Option 2:
A user is paging in the entities and the viewed entities are saving between all users and every time user visit your page.
in that case you probably use all the entities in each category and saving all the viewed entites + check whether a entity is viewed will take some time.
In that option I would get all the ids for this topic- shuffle them and store it in a linked list. when you want to get a random not viewed entity- just get the head of the list and delete it (O(1)).
I assume that for any given <user, category> pair, the number of documents viewed is pretty small relative to the total number of documents available in that category.
So can you just store indexed triples <user, category, document> indicating which documents have been viewed, and then just take an optimistic approach with respect to randomly selected documents? In the vast majority of cases, the randomly selected document will be unread by the user. And you can check quickly because the triples are indexed.
I would opt for a pseudorandom approach:
1.) Determine number of elements in category to be viewed (SELECT COUNT(*) WHERE ...)
2.) Pick a random number in range 1 ... count.
3.) Select a single document (SELECT * FROM ... WHERE [same as when counting] ORDER BY [generate stable order]. Depending on the SQL dialect in use, there are different clauses that can be used to retrieve only the part of the result set you want (MySQL LIMIT clause, SQLServer TOP clause etc.)
If the number of documents is large the chance serving the same user the same document twice is neglibly small. Using the scheme described above you don't have to store any state information at all.
You may want to consider a nosql solution like Apache Cassandra. These seem to be ideally suited to your needs. There are many ways to design the algorithm you need in an environment where you can easily add new columns to a table (column family) on the fly, with excellent support for a very sparsely populated table.
edit: one of many possible solutions below:
create a CF(column family ie table) for each category (creating these on-the-fly is quite easy).
Add a row to each category CF for each document belonging to the category.
Whenever a user hits a document, you add a column with named and set it to true to the row. Obviously this table will be huge with millions of columns and probably quite sparsely populated, but no problem, reading this is still constant time.
Now finding a new document for a user in a category is simply a matter of selecting any result from select * where == null.
You should get constant time writes and reads, amazing scalability, etc if you can accept Cassandra's "eventually consistent" model (ie, it is not mission critical that a user never get a duplicate document)
I've solved similar in the past by indexing the relational database into a document oriented form using Apache Lucene. This was before the recent rise of NoSQL servers and is basically the same thing, but it's still a valid alternative approach.
You would create a Lucene Document for each of your texts with a textId (relational database id) field and multi valued categoryId and userId fields. Populate the categoryId field appropriately. When a user reads a text, add their id to the userId field. A simple query will return the set of documents with a given categoryId and without a given userId - pick one randomly and display it.
Store a users past X selections in a cookie or something.
Return the last selections to the server with the users new criteria
Randomly choose one of the texts satisfying the criteria until it is not a member of the last X selections of the user.
Return this choice of text and update the list of last X selections.
I would experiment to find the best value of X but I have in mind something like an X of say 16?