CosmosDB Ladder pattern - azure-cosmosdb

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”:

Related

Polymer Firebase Binding for Location

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.

Storing timestamp in joining node value instead of Boolean in Firebase database

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.

Meteor: Single-Document Subscription

Whenever I encounter code snippets on the web, I see something like
Meteor.subscribe('posts', 'bob-smith');
The client can then display all posts of "bob-smith".
The subscription returns several documents.
What I need, in contrast, is a single-document subscription in order to show an article's body field. I would like to filter by (article) id:
Meteor.subscribe('articles', articleId);
But I got suspicious when I searched the web for similar examples: I cannot find even one single-document subscription example.
What is the reason for that? Why does nobody use single-document subscriptions?
Oh but people do!
This is not against any best practice that I know of.
For example, here is a code sample from the github repository of Telescope where you can see a publication for retrieving a single user based on his or her id.
Here is another one for retrieving a single post, and here is the subscription for it.
It is actually sane to subscribe only to the data that you need at a given moment in your app. If you are writing a single post page, you should make a single post publication/subscription for it, such as:
Meteor.publish('singleArticle', function (articleId) {
return Articles.find({_id: articleId});
});
// Then, from an iron-router route for example:
Meteor.subscribe('singleArticle', this.params.articleId);
A common pattern that uses a single document subscription is a parameterized route, ex: /posts/:_id - you'll see these in many iron:router answers here.

Most efficient method of pulling in weather data for multiple locations

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.

Prolog: Recursion and splitting lists

I'm trying to write a game in which the program reads through a database, grabs attributes and asks the player if the Movie that the player is thinking of will have that attribute. The user will answer either yes or no and if yes, the game will ask about the next attribute until either the user has said yes to every attribute, at that point the program will output the name of the movie. Or if the user says no, the game will then move along to the next movie in the database and start asking about those attributes.
The game ends when either it finds a movie with all the attributes or there are no more movies in the database in which the program could ask about.
Here is the database file.
object_properties(crocodile_dundee,[comedy,australian,paul_hogan_movie]).
object_properties(flipper,[action_movie,australian, paul_hogan_movie,
-comedy]).
object_properties(jackass,[comedy,-australian]).
object_properties(the_godfather,[drama,crime,-character_batman]).
object_properties(the_dark_knight,[drama,crime,character_batman]).
object_properties(the_living_planet, [documentary,director_attenborough]).
object_properties(the_code, [documentary,nerds_love_it]).
object_properties(the_russian_revolution, [documentary,about_history]).
Here is my game file.
go():-
guess_object(0,[]).
guess_object(Obj,[A|As]) :-
object_categories(Obj,A).
guess_object(1).
guess_object(2).
guess_object(3).
guess_object(4).
guess_object(5). %how do i do this specifically for the current Obj attributes?
guess(X) :- guess_object(_, X),
writeln('Does your object have the attribute '(X)'?'),
read(Input), Input=('yes') -> assert(object(X)) ; retractall(X), guess(X).
writeln('I guess that the film is: 'guess_object(Obj,_).
The main questions I have:
How do I split the object attributes in to a list like I'm trying to do on guess_object(1) through to guess_object(5) depending on whether the object has 2 attributes or 4 attributes, etc.
How do I make my guess(A) predicate recursive so once the user says no it will then go to the next object in the database file?
I'm not too great at prolog but any advice or pointers would be greatly appreciated, even if it's just pointing out a stupid mistake I may have made. I will also answer any questions anyone has to the best of my ability.

Resources