I need opinions. Give me yours
-
So I wrote a wrapper for The Movie DB (tmdb.org) so you can easily and efficiently query for tv show and movie data. It wraps pretty much the entire, very mature REST/json API as an object model so it's enormous. Anyway, the neat thing about it is how it caches. The entire object model backs its state on a normalized graph that maps directly to JSON. it queries tmdb.org as necessary to fill in the bits of the graph it doesn't already have. so it keeps the entire cache as one large (normalized) "JSON" object graph. The normalization just means parsing the json into (null),string,bool, int,long,bigint, double, IList and IDictionary types and then nesting those to make the graphs. I say graphs because the way the cache works, everything is connected, and you might have a node connected by more than one "parent" so that data isn't so duplicated. Anyway, that caching and state backing thing could use its own article. But it's a technique, not a separate code library. Should I publish a Tip & Trick entry with just the caching aspect of the TmdbApi explored, or do you have better ideas? Object graph: Simply objects nested inside objects using dictionaries and lists. (Apparently graph databases are a thing. I did not know that.)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
So I wrote a wrapper for The Movie DB (tmdb.org) so you can easily and efficiently query for tv show and movie data. It wraps pretty much the entire, very mature REST/json API as an object model so it's enormous. Anyway, the neat thing about it is how it caches. The entire object model backs its state on a normalized graph that maps directly to JSON. it queries tmdb.org as necessary to fill in the bits of the graph it doesn't already have. so it keeps the entire cache as one large (normalized) "JSON" object graph. The normalization just means parsing the json into (null),string,bool, int,long,bigint, double, IList and IDictionary types and then nesting those to make the graphs. I say graphs because the way the cache works, everything is connected, and you might have a node connected by more than one "parent" so that data isn't so duplicated. Anyway, that caching and state backing thing could use its own article. But it's a technique, not a separate code library. Should I publish a Tip & Trick entry with just the caching aspect of the TmdbApi explored, or do you have better ideas? Object graph: Simply objects nested inside objects using dictionaries and lists. (Apparently graph databases are a thing. I did not know that.)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I think most people here don't even have a clue what a graph database is and probably think it has to do with graphics, so it would be a good thing to explain that first :-\ Here some Graph databases are mentioned: best-graph-databases-suited-for-big-data[^]
-
I think most people here don't even have a clue what a graph database is and probably think it has to do with graphics, so it would be a good thing to explain that first :-\ Here some Graph databases are mentioned: best-graph-databases-suited-for-big-data[^]
i didn't know a graph database was a thing as such. i'll edit my comment. i was just talking about an object graph. but i suppose that's what a graph DB would hold.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I think most people here don't even have a clue what a graph database is and probably think it has to do with graphics, so it would be a good thing to explain that first :-\ Here some Graph databases are mentioned: best-graph-databases-suited-for-big-data[^]
-
i didn't know a graph database was a thing as such. i'll edit my comment. i was just talking about an object graph. but i suppose that's what a graph DB would hold.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Why is this now playing in my head: Billy Joel - Honesty[^] :-\
-
I've used neo4j and would recommend it if you use Java. They have a really good intro article to the topic too - What is a Graph Database?[^] :thumbsup:
this one is all in C#. It's not really a full fledged DB. It's simplistic but good for what i needed it to do. Literally all the "indexers" are are just thinly wrapped
Dictionaryinstances. EachDictionaryis a JSON object. EachList is a JSON array. The scalar values for `object` can be numeric, string, boolean or null, just like JSON, but they can also be more lists and dictionaries. It all maps directly. It's so easy it's stupid, but smart enough to work. When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite. -
I've used neo4j and would recommend it if you use Java. They have a really good intro article to the topic too - What is a Graph Database?[^] :thumbsup:
There is a free Ebook about Neo4j here: Graph Databases, published by O'Reilly Media[^]
-
There is a free Ebook about Neo4j here: Graph Databases, published by O'Reilly Media[^]
I've heard of it, but it's overkill for this. If this was serving json rather than consuming it I'd consider it, but all i need is simple caching.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
So I wrote a wrapper for The Movie DB (tmdb.org) so you can easily and efficiently query for tv show and movie data. It wraps pretty much the entire, very mature REST/json API as an object model so it's enormous. Anyway, the neat thing about it is how it caches. The entire object model backs its state on a normalized graph that maps directly to JSON. it queries tmdb.org as necessary to fill in the bits of the graph it doesn't already have. so it keeps the entire cache as one large (normalized) "JSON" object graph. The normalization just means parsing the json into (null),string,bool, int,long,bigint, double, IList and IDictionary types and then nesting those to make the graphs. I say graphs because the way the cache works, everything is connected, and you might have a node connected by more than one "parent" so that data isn't so duplicated. Anyway, that caching and state backing thing could use its own article. But it's a technique, not a separate code library. Should I publish a Tip & Trick entry with just the caching aspect of the TmdbApi explored, or do you have better ideas? Object graph: Simply objects nested inside objects using dictionaries and lists. (Apparently graph databases are a thing. I did not know that.)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
Anyway, that caching and state backing thing could use its own article. But it's a technique, not a separate code library. Should I publish a Tip & Trick entry with just the caching aspect of the TmdbApi explored, or do you have better ideas?
It sounds like it would fit better as an Article than as a Tip (unless I'm overestimating the amount you can write about it). But it doesn't matter that it's a technique instead of a code library... there's no problem whatsoever with writing an article about a technique.
-
So I wrote a wrapper for The Movie DB (tmdb.org) so you can easily and efficiently query for tv show and movie data. It wraps pretty much the entire, very mature REST/json API as an object model so it's enormous. Anyway, the neat thing about it is how it caches. The entire object model backs its state on a normalized graph that maps directly to JSON. it queries tmdb.org as necessary to fill in the bits of the graph it doesn't already have. so it keeps the entire cache as one large (normalized) "JSON" object graph. The normalization just means parsing the json into (null),string,bool, int,long,bigint, double, IList and IDictionary types and then nesting those to make the graphs. I say graphs because the way the cache works, everything is connected, and you might have a node connected by more than one "parent" so that data isn't so duplicated. Anyway, that caching and state backing thing could use its own article. But it's a technique, not a separate code library. Should I publish a Tip & Trick entry with just the caching aspect of the TmdbApi explored, or do you have better ideas? Object graph: Simply objects nested inside objects using dictionaries and lists. (Apparently graph databases are a thing. I did not know that.)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
This could become a very valuable CP article.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
There is a free Ebook about Neo4j here: Graph Databases, published by O'Reilly Media[^]
Neo4j is quite interesting: it runs on java. The free book is very well-written.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
There is a free Ebook about Neo4j here: Graph Databases, published by O'Reilly Media[^]
Neo4j is quite interesting: it runs on Java. The free book is very well-written.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
This could become a very valuable CP article.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
I wonder how many services out there expose their APIs as JSON (content-type: application/json) over HTTP REST? If so, I might have a dynamic, (read-only) caching entity framework for querying such a monster. All of the really cool stuff though - like the automatic paging is very service specific regardless.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I wonder how many services out there expose their APIs as JSON (content-type: application/json) over HTTP REST? If so, I might have a dynamic, (read-only) caching entity framework for querying such a monster. All of the really cool stuff though - like the automatic paging is very service specific regardless.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
This site provides access to lots of API's: https://rapidapi.com/[^]