I will be receiving flat documents that will have slightly different schemas.
For example:
{
"FirstName": "Jim",
"LastName: "Bob"
}
And another one, that would simply have:
{
"FullName": "Jim Bob"
}
Is it possible to query the Person collection to retrieve the list of unique properties (not the values)?
[
"FirstName",
"LastName",
"FullName"
]
According to my research, it is not supported in cosmos db query syntax so far. You could refer to this similar feedback and adopt the suggestions from cosmos db team.
Also, I think you could get all the names of properties by below coding workaround.
Create and init a hashmap.
Query the documents and get the results array.
Loop the array and convert every json to map.
Push the elements into initial hashmap to make sure the list of properties is unique.
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
Here is a tv show query. How do I get the request to pull in the wiki summary?
[{
"id" : "/m/0d68qy",
"name": null
}]
The topic summary is linked to a topic via the /common/topic/article property. You can retrieve this data in one API call using the new Topic API like this:
https://www.googleapis.com/freebase/v1/topic/m/0d68qy?filter=/common/topic/article
I have the following MQL query which successfully returns the record for William Shakespeare.
[{
"/type/object/name": null,
"/type/object/id": "/en/william_shakespeare"
}]
http://tinyurl.com/cnpma3f
I am trying to get the description attribute. When I add "description": null, I get a 'no description attribute found' error. Yet, looking at the record in freebase, it should be there:
http://www.freebase.com/experimental/topic/standard/en/william_shakespeare
The topic API aggregates results across a number of Freebase services; the descriptions are stored separately from the other data about a topic and you'll have to use the text service to fetch them, rather than MQL directly.
As an aside, you should probably consider changing to the new Freebase APIs; those hosted at (www|api).freebase.com are deprecated and will (allegedly) be turned off in October.
I am trying to get a list of items using a list of MIDs
Previously I asked this question Array of Freebase MIDs and sending multiple queries to freebase
So my MQL query looks like this now:
[{
"mid": null,
"name": null,
"topics:mid|=":[
"/m/045c7b",
"/m/0d6lp",
"/m/021ympy",
...
]
}]
Sample MQL Query URL
However, the default order seems to be based on something like index or timestamp. I would like the order of the results to mirror the order the MIDs are listed in the query - is this possible? If so, any hints on what the MQL would look like would be awesome :)
Not possible with MQL - you'll have to do the sorting client-side. For what it's worth, the default order is undefined, so don't rely on it for anything.