In Freebase API, I want to fetch related objects to an object in Freebase. For example:
When I type in "Michael Jordan" (http://www.freebase.com/m/054c1) it should return "Chicago Bull's" (http://www.freebase.com/m/0jm74).
I went over https://developers.google.com/freebase/v1/search-cookbook but couldn't come up with a filter operand.
Any ideas?
I don't know which API you are using, but if you were to use the Freebase Search API, you would get the mid of the entity, then plug that back in to another search appropriate to that entity. The code below (in Javascript w/ jQuery) limits the input possibilities to a field where Mr.Jordan is present, then plugs it into a property found on basketball players: former teams.
$(function()
{
$("#myInput").suggest().bind("fb-select", function(e, data)
{
var topic_service = 'https://wwwlgoogleapis.com/freebase/v1/topic';
var params = {
'filter' : '(all type:/sports/sports_award_winner)'
};
$.getJSON(topic_service + data.id + '?callback=?', params, function(topic)
{
var teams = data.property['/basketball/basketball_player/former_teams']['values'];
for ( var i = 0; i < teams.length; i++)
{
alert(teams[i]);
}
})
})
});
You could do this without limiting the search, for more general types, but then you would have to do a query for what properties were held by that entity and then use that as a filter to get the data you were after.
On the other hand...
If you don't know that Jordan plays basketball, or what the properties of a basketball player are, you could call for the id of the links, find the properties of those links, then query for those properties on those links:
{
"mid": "/en/michael_jordan",
"type": [{
"id":null,
"properties": [{
"id":null,
"links": [{
"source": {
"id": "/en/michael_jordan"
},
"target": {
"id": null,
"optional": true,
},
"optional": true,
"target_value": null
}],
"master_property": {
"optional": true,
"links": [{
"source": {
"id": null
},
"target": {
"id": "/en/michael_jordan"
}
}]
}
}]
}
--This code is taken from the slide pack of an I/O talk given by Jamie Taylor in 2011.
Related
Is it a violation of the JSON-API spec to allow reverse relationships to be created automatically?
I need to create resources that, when I link A to B in a relationship, automatically links B to A. In this way I can traverse A to find all of its Bs and can find the parent A from a B. However, I don't want to POST/PATCH to 2 relationships to get this right. I want to establish the relationship once.
Now I know that it is an implementation detail as to how the server maintains link/references as well as how the behaviour is established but I want to build the API in such a way that it doesn't violate the spec.
Assuming I have resources Books and Authors. Books have Authors and Authors have Books. The question is, once I relate an Author to a Book, I need the reverse relationship to be created as well. Is it a violation of the spec in any way to assume that this reverse relationship can be automatically created by simply doing one POST to the Books resource's relationship?
By way of example, starting with the book.
{
"data": {
"type": "books", "id": 123, "attributes": ...,
"links": { "self": "/books/123" },
"relationships": {
"self": "/books/123/relationships/authors",
"related": "/books/123/authors"
}
}
}
And the author
{
"data": {
"type": "authors", "id": 456, "attributes": ...,
"links": { "self": "/authors/456" },
"relationships": {
"self": "/authors/456/relationships/books",
"related": "/authors/456/books"
}
}
}
If I establish the link from a book to an author with a POST to /books/123/relationships/authors
{
"data": [{ "data": "authors", "id": "456" }]
}
Do I need to explicitly do the same for the Author 456 as a POST to /authors/456/relationships/books?
{
"data": [{ "data": "books", "id": "123" }]
}
Or can I let the server build the relationship for me so that I can avoid the second POST and just see the automatic reverse relationship at GET /authors/456/relationships/books?
From the perspective of the spec this is only one relationship represented from two different sides. author and book have a many-to-many relationship. This relationship could be represented in author's resource object as well as book's resource object and of course also via there relationship links. Actually it would be a violation of the spirit of the specification if representations wouldn't match. Having one-sided relationships is another story but in that case one side wouldn't know about the relationships at all (e.g. a book is associated with an author but the author model does not know which books are associated with it).
A post to either one side of that relationship creates the relationship between the two records. It shouldn't matter which side is used to create that relationship and if it's created as part of a creation / update to a resource via it's resource object or via a relationship link representing that relationship. The same applies to deletion of that relationship.
Maybe an example would make that even more clear. Let's assume a book is created with a POST to /books?include=author having these payload:
{
"data": {
"type": "books",
"relationships": {
"author": {
"data": {
"type": "authors",
"id": "1"
}
}
}
}
}
The response may look like this:
{
"data": {
"type": "books",
"id": "7",
"relationships": {
"author": {
"data": { "type": "authors", "id": "1" }
}
}
},
"included": [
{
"type": "authors",
"id": "1",
"relationships": {
"books": {
"data": [
{ "type": "books", "id": "7" }
]
}
}
}
]
}
So I have an item in DynamoDB:
{
"id": "1",
"foo": "bar"
}
And I want to add a new attribute to said item, the attribute being:
{
"newAttr": [{ "bar": 1 }, { "bar": 2 }, { "bar": 3 }]
}
Now I'm doing this in JS using the AWS-SDK like so:
client.update({
ExpressionAttributeNames: { '#newAttr': 'newAttr' },
ExpressionAttributeValues: { ':newAttr': newAttr },
Key: { "id": "1" },
TableName: "foo",
UpdateExpression: "SET #newAttr = :newAttr"
}, callback)
However, I get an error:
ExpressionAttributeValues contains invalid value: One or more
parameter values were invalid: An AttributeValue may not contain an
empty string for key :newAttr
So if I were to JSON.stringify(newAttr) then it's fine, but I don't want this new attribute to be a string, I want it to be a list.
So what am I doing wrong?
Try ADD instead of SET
client.update({
ExpressionAttributeNames: { '#newAttr': 'newAttr' },
ExpressionAttributeValues: { ':newAttr': newAttr },
Key: { "id": "1" },
TableName: "foo",
UpdateExpression: "ADD #newAttr = :newAttr"
}, callback)
I ended up having these issues in the beginning. I'm sure you are wasting time in writing in all the low-level code to interact with DynamoDB.
Use an ODM (ORM Like) for document storage which handles all the hurdles for you.
https://github.com/clarkie/dynogels
is what I have used and will make your life much easier.
Empty String are not allowed
One cannot store empty strings with DynamoDB at the root level. You can have it in the nested objects.
Allowed Data Types from DynamoDB:
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html
Hope this helps.
With the sample json shown below, am trying to retrieve all documents that contains atleast one category which is array object wrapped underneath Categories that has the text value 'drinks' with the following query but the returned result is empty. Can someone help me get this right?
SELECT items.id
,items.description
,items.Categories
FROM items
WHERE ARRAY_CONTAINS(items.Categories.Category.Text, "drink")
{
"id": "1dbaf1d0-6549-11a0-88a8-001256957023",
"Categories": {
"Category": [{
"Type": "GS1",
"Id": "10000266",
"Text": "Stimulants/Energy Drinks Ready to Drink"
}, {
"Type": "GS2",
"Id": "10000266",
"Text": "Healthy Drink"
}]
}
},
Note: The json is a bit wierd to have the array wrapped by an object itself - this json was converted from a XML hence the result. So please assume I do not have any control over how this object is saved as json
You need to flatten the document in your query to get the result you want by joining the array back to the main document. The query you want would look like this:
SELECT items.id, items.Categories
FROM items
JOIN Category IN items.Categories.Category
WHERE CONTAINS(LOWER(Category.Text), "drink")
However, because there is no concept of a DISTINCT query, this will produce duplicates equal to the number of Category items that contain the word "drink". So this query would produce your example document twice like this:
[
{
"id": "1dbaf1d0-6549-11a0-88a8-001256957023",
"Categories": {
"Category": [
{
"Type": "GS1",
"Id": "10000266",
"Text": "Stimulants/Energy Drinks Ready to Drink"
},
{
"Type": "GS2",
"Id": "10000266",
"Text": "Healthy Drink"
}
]
}
},
{
"id": "1dbaf1d0-6549-11a0-88a8-001256957023",
"Categories": {
"Category": [
{
"Type": "GS1",
"Id": "10000266",
"Text": "Stimulants/Energy Drinks Ready to Drink"
},
{
"Type": "GS2",
"Id": "10000266",
"Text": "Healthy Drink"
}
]
}
}
]
This could be problematic and expensive if the Categories array holds a lot of Category items that have "drink" in them.
You can cut that down if you are only interested in a single Category by changing the query to:
SELECT items.id, Category
FROM items
JOIN Category IN items.Categories.Category
WHERE CONTAINS(LOWER(Category.Text), "drink")
Which would produce a more concise result with only the id field repeated with each matching Category item showing up once:
[{
"id": "1dbaf1d0-6549-11a0-88a8-001256957023",
"Category": {
"Type": "GS1",
"Id": "10000266",
"Text": "Stimulants/Energy Drinks Ready to Drink"
}
},
{
"id": "1dbaf1d0-6549-11a0-88a8-001256957023",
"Category": {
"Type": "GS2",
"Id": "10000266",
"Text": "Healthy Drink"
}
}]
Otherwise, you will have to filter the results when you get them back from the query to remove duplicate documents.
If it were me and I was building a production system with this requirement, I'd use Azure Search. Here is some info on hooking it up to DocumentDB.
If you don't want to do that and we must live with the constraint that you can't change the shape of the documents, the only way I can think to do this is to use a User Defined Function (UDF) like this:
function GetItemsWithMatchingCategories(categories, matchingString) {
if (Array.isArray(categories) && categories !== null) {
var lowerMatchingString = matchingString.toLowerCase();
for (var index = 0; index < categories.length; index++) {
var category = categories[index];
var categoryName = category.Text.toLowerCase();
if (categoryName.indexOf(lowerMatchingString) >= 0) {
return true;
}
}
}
}
Note, the code above was modified by the asker after actually trying it out so it's somewhat tested.
You would use it with a query like this:
SELECT * FROM items WHERE udf.GetItemsWithMatchingCategories(items.Categories, "drink")
Also, note that this will result in a full table scan (unless you can combine it with other criteria that can use an index) which may or may not meet your performance/RU limit constraints.
Why is the self and related references different in the below JSONAPI resource? Aren't they pointing to the same resource? What is the difference between going to /articles/1/relationships/tags and /articles/1/tags?
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
You can read about that here: https://github.com/json-api/json-api/issues/508.
Basically, with /articles/1/relationships/tags response will be object which represents relationship between articles and tags. The response could be something like this (what you put in your question):
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
This response gives only the necessary data (in primary data attribute - data) to manipulate the relationship and not resources connected with relationship. That being said, you'll call /articles/1/relationships/tags if you want to create new relationship, add a new tag (basically updating relationship) to article, read which tags belong to article (you only need identity to search them on server) or delete article tags.
On the other hand, calling /articles/1/tags will respond with tags as primary data with all the other properties that they have (articles, relationships, links, and other top-level attributes such include, emphasized text, links and/or jsonapi).
They are different. Here is an example from my project.
Try Get http://localhost:3000/phone-numbers/1/relationships/contact you will get response like this:
{
"links": {
"self": "http://localhost:3000/phone-numbers/1/relationships/contact",
"related": "http://localhost:3000/phone-numbers/1/contact"
},
"data": {
"type": "contacts",
"id": "1"
}
}
You didn't get the attributes and relationships which is probably you want to retrieve.
Then
Try Get http://localhost:3000/phone-numbers/1/contact you will get response like this:
{
"data": {
"id": "1",
"type": "contacts",
"links": {
"self": "http://localhost:3000/contacts/1"
},
"attributes": {
"name-first": "John",
"name-last": "Doe",
"email": "john.doe#boring.test",
"twitter": null
},
"relationships": {
"phone-numbers": {
"links": {
"self": "http://localhost:3000/contacts/1/relationships/phone-numbers",
"related": "http://localhost:3000/contacts/1/phone-numbers"
}
}
}
}
}
You can see you retrieved all the information you want, including the attributes and relationships.
But you should know that relationships can be used for some purpose. Please read http://jsonapi.org/format/#crud-updating-to-one-relationships as a sample.
Say I'm trying to get properties from a film. I can run the following which will return an array of actors:
{"type":"/film/film","id":"/m/05ggnq",
"starring":[{"mid":null,"actor":null,"character":null}]
}
However, when I try to query for another property that may or may not exist ("story_by") I simply get back an empty 200 response.
{"type":"/film/film","id":"/m/05ggnq", "story_by":[{"mid":null}],
"starring":[{"mid":null,"actor":null,"character":null}]
}
How am I suposed to search for both of these properties at the same time?
You can do this using the optional directive like this:
{
"type": "/film/film",
"id": "/m/05ggnq",
"story_by": [{
"mid": null,
"optional": true
}],
"starring": [{
"mid": null,
"actor": null,
"character": null
}]
}