I tried to find answer to what is a content node, couldn't find it. What exactly is a content node in Freebase? Isn't it a topic like others?
Content nodes are nodes that are used as proxies for content blobs like topic descriptions and images. Since this sort of content is stored outside of the Freebase graph it needs these nodes in the graph so that this content can be linked to by topics.
Freebase is in the process of moving topic descriptions into the graph but images remain as content nodes.
You can see the image content node for the topic San Francisco with the following MQL query:
{
"id": "/m/0d6lp",
"name": null,
"/common/topic/image": [{}]
}
Then, using the IDs from the image content nodes, you can access the images via the API like this:
https://www.googleapis.com/freebase/v1/image/m/04j74yh
Related
I have an architectural / best practices question regarding react and redux.
I'm using redux middleware to query a graphql service and expose the result in props to connected components. One of the advantages of graphql is being able to retrieve only the information you need using their query format.
I have a page that lists entities and when you click a specific entity you get a view entity detail page with the id in the query string.
I want an array of entities in my state to be my single source of truth and a selectedEntityId property to serve as a lookup on that list of entities.
My problem is that the list of entities in the list page is just the name and description while the view page contains much much more information.
Solutions I can think of:
1) Retrieve all the entities information (not just name and description) in the list page (and view page). The problem is that I'd be querying a bunch of information I don't need on the list page which goes against the idea of graphql.
2) Have 2 properties on my state. One will contain entities with just name and description while the other property will contain a list of entities with more information. The problem with this solution is that I have 2 single sources of truth.
3) I can "marry" the 2 entity lists, so if I navigate from a list to a view page, I can saturate the list of entities I already have from the list page with the entities I get from the view page (the entities with many more properties besides name and description) and use that list as my single source of truth. This seems to be the best solution but I don't know a clean way to do this.
Can anyone shed light on the situation?
Thanks!
I'm not sure if thats the best one, but based on your solutions, I would say the third works alright.
You could try adding a new value to each list item that identifies if the specific item has all the details or not.
Imagine the store like so:
items: {
id1: {
isFull: false,
title: 'Item 1',
id: 'id1'
},
id2: {
isFull: true,
title: 'Item 2',
id: 'id2',
description: '..',
lorem: '',
...
}
}
Then get isFull in the details page and fetch in case of false.
Using the Firebase database I need to decide how to organize the user / post(e.g a tweet) relation. Two common reading tasks include:-
Showing an overview of a user's posts
Filtering and selecting specific posts based on their content
I currently use this:
posts
randproject1234jdfs
user_uid: randomUserName1234,
content: "example"
users
randomUserName1234
posts
project_id: randproject1234jdfs
nickname: "Mr Example"
This stores the same information twice:
In posts/randstring1234jdfs/user_uid , the value points to the user.
In users/1234/posts the project_id point to the post.
Would removing one of these lead to significantly slower data-reading (having to loop through the entire folder to see if the user_uid/project_id matches the given post/user)?
Or would it be better to organize the data in a different way altogether (e.g removing the user/posts split)?
You want to do the following:
Showing an overview of a user's posts
Filtering and selecting specific posts based on their content
You can do this then:
posts
randomid
user_uid: randomUserName1234,
content: "example"
posttitle: "English"
randomid2
user_uid: randomUserName1235,
content: "examples"
posttitle: "Math"
users
randomUserName1234 <-------------------- userid
email: email#gmail.com
nickname: "Mr Example"
randomUserName1235<--------------------anotheruserid
email: email#gmail.com
nickname: "Mr Awesome"
Since you want to show the user's post, then you can just query the node posts something like this: orderByChild(user_uid).equalTo(randomUserName1234) using that you can retrieve the content which are the posts I guess.
To retrieve posts of any user depending on content using the above u can do this:
orderByChild("posttitle").equalTo("English") and then retrieve the node content which I'am assuming they are the posts.
Remember denormalization is normal and it is important or you will have a hard time doing the queries. https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html
The user node let it have the list of users in this app for example.
The posts node will be like above and it will be connected to the user by having this user_uid: randomUserName1235 as seen above.
I am developing the browser front end of a social network application. It has lots of relational data, having one-to-many (1:m) and mostly many-to-many (m:m) relationships as in below list.
I want to use Flux data flow architecture in the application. I am using Vuex.js with Vue.js.
As expressed in the Redux.js docs it is better to have flat, normalized, store state shape for various reasons for usage with React, and I think that is the case for usage with Vue.js also.
posts have categories (m:m)
posts have tags (m:m)
post has comments (1:m)
posts have hashtags in them (m:m) // or users creates hashtags
posts have mentions in them (m:m) // or users creates mentions of users
users like posts (m:m)
users follow users, posts, post categories etc. (m:m)
users favorite posts (m:m)
etc.
I will need to show post feeds with all of its related data of other entities like users, comments, categories, tags. For this, like having a 1:many relation, holding the many side of this relation's data in the one side (can be said to be the parent), even it is actually many-to-many, seems ok for usual querying of them to compose their parent, that is posts. However, I will need to query the store state inversely also, for example, getting the posts with a certain category or tag.
In that case, it is not as easy is as doing so for posts. I need a relation entity that holds the id pairs for the two connected data entity, just like a join table or association table in RDBMSs, for ease of accessing and updating, avoiding deep digging into state, and also avoiding unnecessary re-renders (that requirement is React or Vue.js and GUI specific).
How can I achieve this relatively easily and effectively, e.g. as one do for 1:many relations?
Pursuant to your last comment. I'll present the data structure I currently use for this circumstance:
Tag
{
"type": "tag",
"id": "tag1",
"name": "Tag One"
}
Tag To Post
{
"id": "someId",
"type": "postTag",
"tagId": "tag1",
"postId": "post1"
}
Post
{
"id": "post1",
"name": "Post 1"
}
I found that each side of M:M storing the relationship ids potentially produces orphans. The management of these IDs in dual places leads to replicating steps and an increase in cognitive management as all functions managing the M:M happen in two places rather than one. Additionally, the relationship itself may need to contain data, where would this data go?
M:M Without Entity
{
"id": "post1",
"name": "Post 1"
"tagIds": [
{id: "tag1", extraAttribute: false} //this is awkward
]
}
Tag To Post - Additional Attributes
{
"id": "someId",
"extraAttribute": false,
"postId": "post1"
"type": "postTag",
"tagId": "tag1",
}
There are additional options available to speed up extracting tags with minor elbow grease.
Post
{
"id": "post1",
"name": "Post 1"
"tagIds" : ["tag1", "tag4"]
}
Hypothetically, a post would not have more than 20 tags. Making this a generally negligible storage requirement to reduce lookups. I have found no urgent need for this currently with a database of 10000 relationships.
Ease of access and updating
1:M is an object directly pointing at what it wants. M:M are two different entities pointing at their relationships. Model that relationship, and centralise the logic
Rerenders
If your application renders long lists of data (hundreds or thousands
of rows), we recommended using a technique known as “windowing”. This
technique only renders a small subset of your rows at any given time,
and can dramatically reduce the time it takes to re-render the
components as well as the number of DOM nodes created.
https://reactjs.org/docs/optimizing-performance.html#virtualize-long-lists
I feel solutions may be use case specific and subject to broader opinions. I ran into this issue utilising couch/pouch with Vuex and a very large table of 20,000 entries. Again, in production the issues were not extremely noticeable. Results will always vary.
A couple things I try here:
Load partial data sets: in-file (non-reactive) vs in memory (loaded in Vuex)
Sort, paginate, search in-file and load results
I have fetched data publicly to my blog from firebase database.
I wonder if this kind of thing could be done:
During search in blog, is it can bind together with the firebase fetched data? If it is can be done...then marvellous!
Thanks!
Extra info:
This is my sample blog.
As you can see, the list was fetched from firebase. I would like to let the user able to search on that list also.
The search area was at Cari area at the right top div.
Here..I tried to search something like this:
I have the following problem:
I created content type "movies" and content type "actors". I added a node reference to the "actors" which links to movies. When i create new actor content I'm able to select movie from node reference. So, I created a list inside Views which shows you a list of actors and next to the actor it displays one of the movies they were in. I did this through node reference in "actors".
Ok, so here is the problem. I now want to create a list of movies and actor next to the movie. I know I can solve this problem if I create another node reference inside movies and every time I create movie content I would need to select actors attached to the movie. Is there a way to do what I need without creating another node reference. I want to use already existing node reference inside actors and show actor depending on the movie selected for the actor.
Can some one please help me with this problem? Im really stuck.
Thank You,
Toliy
You can install the nodereferrer module to provide a counterpart to the node reference fields. It makes node references accessible in both directions so you can do this sort of thing.
Just found out about this, which handles bidirectional relations.
I've also had a lot of success with the Corresponding Node Reference
After you set up your two node references, you can use simple checkboxes to ensure that they are linked up.