I have hundreds of keywords, which I need to query in the Mongo database. So far I'm doing it like that:
{keyword: 'lampa stołowa'}
{keyword: 'lampa na stół'}
{keyword: 'lampa do pokoju'}
however doing it one by one takes ages (I'm doing it in Rstudio, but still it takes a long time).
Anybody knows how to do it for all the keywords at once? Hopefully it would be faster.
It seems I found an answer:
{keyword: { $in:["lampa stołowa", "lampa nad stół", "lampa do pokoju"]} }
Related
I'm reading this documentation https://blogs.msdn.microsoft.com/mvpawardprogram/2016/03/15/going-social-with-documentdb/ … it talks about a “Ladder pattern” but there are no examples and I can't seem to find this anywhere else. Could I get a little more direction on this concept?
I want to update all data duplicates with a pattern so i can update the main records and don't need to worry about it updating it everywhere its duplicated or reference.
You are looking at old documentation,
check the updated one on The “Ladder” pattern and data duplication
Let’s take user information as an example:
{
"id":"dse4-qwe2-ert4-aad2",
"name":"John",
"surname":"Doe",
"address":"742 Evergreen Terrace",
"birthday":"1983-05-07",
"email":"john#doe.com",
"twitterHandle":"#john",
"username":"johndoe",
"password":"some_encrypted_phrase",
"totalPoints":100,
"totalPosts":24
}
By looking at this information, we can quickly detect which is critical information and which isn’t, thus creating a “Ladder”:
I've been trying to bind a location value to a "note" (as in the na-notes example in codelabs) via firebase. I'm using the paper-input-place, but have tried with several other elements to no avail. So far, this is what I have (corresponding to the na-note.html document):
<paper-input-place is="iron-input" bind-value="{{address}}" value="{{address}}" label="Address" api-key="key">
And then I have this on my na-editor.html:
<na-note id="note" title="{{note.title}}" location="{{note.place_id}}" price="{{note.price}}" rooms="{{note.rooms}}" beds="{{note.beds}}" baths="{{note.baths}}" editable></na-note>
I am thinking that it probably is a silly mistake, but I've been going at it for two days and I'm starting to loose my patience, so any help would be appreciated!
Thanks!
at above na-note element, note is an object retrieved from firebase. so, to this path, you will need to save location data of the note. So, when you received the proper data from paper-input-place element, you will need to save it to the note's path as a location. So, first retrive the address:
<paper-input-place hide-error place="{{place}}" api-key="[[apiKey]]" on-place-changed="searchPlaceChanged" > </paper-input-place>
...
searchPlaceChanged(p){
console.log(p.detail.value); // You will need to see the place data, which you may like to save only some detail like: p.detail.value.formatted_address;
this.set('note.place', p.detail.value.formatted_address);
}
Asuming just abobe note object (at set operation) is firebase-document's two way binding retrived data that you just editing.
Say that I have node user, item and user_items used to join them.
Typically one would(as advised in official documents and videos) use such a structure:
"user_items": {
"$userKey": {
"$itemKey1": true,
"$itemKey2": true,
"$itemKey3": true
}
}
I would like to use the following structure instead:
"user_items": {
"$userKey": {
"$itemKey1": 1494912826601,
"$itemKey2": 1494912826602,
"$itemKey3": 1494912826603
}
}
with values being a timestamp value. So that i can order them by creation date also while being able to tell the associated time. Seems like killing two birds with one stone situation. Or is it?
Any down sides to this approach?
EDIT: Also I'm using this approach for the boolean fields such as: approved_at, seen_at,... etc instead of using two fields like:
"some_message": {
"is_seen": true,
"seen_timestamp": 1494912826602,
}
You can model your database in every way you want, as long as you follow Firebase rules. The most important rule is to have the data as flatten as possible. According to this rule your database is structured correctly. There is no 100% solution to have a perfect database but according to your needs and using one of the following situations, you can consider that is a good practice to do it.
1. "$itemKey1": true,
2. "$itemName1": true,
3. "$itemKey1": 1494912826601,
4. "$itemName1": 1494912826601,
What is the meaning of "$itemKey1": 1494912826601,? Beacause you already have set a timestamp, means that your item was uploaded into your database and is linked to the specific user, which means also in other words true. So is not a bad approach to do something like this.
Hope it helps.
Great minds must think alike, because I do the exact same thing :) In my case, the "items" are posts that the user has upvoted. I use the timestamps with orderBy(), along with limitToLast(50) to get the "last 50 posts that the user has upvoted". And from there they can load more. I see no downsides to doing this.
In the openstreetmap overpass API-documentation there is the following example:
area[name="Bonn"];
node(area)[highway=bus_stop];
node(around:100)[amenity=cinema];
out;
Why does this query does not give the Kinopolis (in Bonn Bad Godesberg) as a result? See here: http://rpubs.com/hrbrmstr/overpass for the results from the API. The following two images illustrate that it really is <100m by foot.
Unfortunately i wasnt able to show it graphically on the openstreetmap... I dont know how to get the busstop as startingpoint of a route in the web interface...
Here is the Google-Maps version.
Since you've asked for cinema nodes only in your example query, the result will not include way 42473787. Here's how your query should look like to return ways with amenity=cinema instead:
area[name="Bonn"];
node(area)[highway=bus_stop];
way(around:100)[amenity=cinema];
(._;>;);
out meta;
To get both nodes and ways in one query, simply use a union:
area[name="Bonn"];
node(area)[highway=bus_stop]->.bus_stops;
(
way(around.bus_stops:100)[amenity=cinema];
node(around.bus_stops:100)[amenity=cinema];
);
(._;>;);
out meta;
Try it in overpass turbo!
I'm working on a meteor mobile app that displays information about local places of interest and one of the things that I want to show is the weather in each location. I've currently got my locations stored with latlng coordinates and they're searchable by radius. I'd like to use the openweathermap api to pull in some useful 'current conditions' information so that when a user looks at an entry they can see basic weather data. Ideally I'd like to limit the number of outgoing requests to keep the pages snappy (and API requests down)
I'm wondering if I can create a server collection of weather data that I update regularly, server-side (hourly?) that my clients then query (perhaps using a mongo $near lookup?) - that way all of my data is being handled within meteor, rather than each client going out to grab the latest data from the API. I don't want to have to iterate through all of the locations in my list and do a separate call out to the api for each as I have approx. 400 locations(!). I'm afraid I'm new to API requests (and meteor itself) so apologies if this is a poorly phrased question.
I'm not entirely sure if this is doable, or if it's even the best approach - any advice (and links to any useful code snippets!) would be greatly appreciated!
EDIT / UPDATE!
OK I haven't managed to get this working yet but I some more useful details on the data!
If I make a request to the openweather API I can get data back for all of their locations (which I would like to add/update to a collection). I could then do regular lookup, instead of making a client request straight out to them every time a user looks at a location. The JSON data looks like this:
{
"message":"accurate",
"cod":"200",
"count":50,
"list":[
{
"id":2643076,
"name":"Marazion",
"coord":{
"lon":-5.47505,
"lat":50.125561
},
"main":{
"temp":292.15,
"pressure":1016,
"humidity":68,
"temp_min":292.15,
"temp_max":292.15
},
"dt":1403707800,
"wind":{
"speed":8.7,
"deg":110,
"gust":13.9
},
"sys":{
"country":""
},
"clouds":{
"all":75
},
"weather":[
{
"id":721,
"main":"Haze",
"description":"haze",
"icon":"50d"
}
]
}, ...
Ideally I'd like to build my own local 'weather' collection that I can search using mongo's $near (to keep outbound requests down, and speed up), but I don't know if this will be possible because the format that the data comes back in - I think I'd need to structure my location data like this in order to use a geo search:
"location": {
"type": "Point",
"coordinates": [-5.47505,50.125561]
}
My questions are:
How can I build that collection (I've seen this - could I do something similar and update existing entries in the collection on a regular basis?)
Does it just need to live on the server, or client too?
Do I need to manipulate the data in order to get a geo search to work?
Is this even the right way to approach it??
EDIT/UPDATE2
Is this question too long/much? It feels like it. Maybe I should split it out.
Yes easily possible. Because your question is so large I'll give you a high level explanation of what I think you need to do.
You need to create a collection where you're gonna save the weather data in.
A request worker that requests new data and updates the collection on a set interval. Use something like cron-tick for scheduling the interval.
Requesting data should only happen server side and I can recommend the request npm package for that.
Meteor.publish the weather collection and have the client subscribe to that, with optionally a filter for it's location.
You should now be getting the weather data on your client and should be able to get freaky with it.