I am using laravel 5.5.13.
I have App\Entity which has many App\Comment's and many App\Thumb's.
Now I am able to fetch the Comments and Thumbs easily like this:
public function show(Entity $entity)
{
return $entity->load('comments')->load('thumbs');
}
This gives data like this:
{
"id": 1,
"kind": null,
"name": "three",
"created_at": "2017-11-01 04:29:22",
"updated_at": "2017-11-01 04:29:22",
"comments": [
{
"id": 5,
"body": "no non o",
"displayname_id": 4,
"entity_id": 1,
"created_at": "2017-11-01 05:16:14",
"updated_at": "2017-11-01 05:16:14"
}
],
"thumbs": [
{
"id": 9,
"like": 0,
"displayname_id": 5,
"entity_id": 1,
"created_at": "2017-11-01 05:16:39",
"updated_at": "2017-11-01 05:16:39"
}
]
}
However, I also need a list of the $comment->displaynames() and $thumb->displaynames() and also each comment has many App\Votes via the $comment->votes(). Is it possible. I read lots on pivot but I am real confused.
My goal is to get data like this:
{
// removed for concise (same as above)
"comments": [
{
// removed for concise (same as above)
"votes": [
..... // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I want to get this
]
},
{
// removed for concise (same as above)
"votes": [
..... // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I want to get this
]
}
],
"thumbs": [
{
// removed for concise (same as above)
}
],
"displaynames": [
..... // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I want to get this
]
}
We see here the new displaynames array and a votes array in each comment.
Do i have to use pivot here to in a one-to-many relationship?
Your controller:
Entity::
with(['comments' => function($query){
$query->with('votes');
}, 'thumbs' => function($query){
$query->with('votes');
}])
->find($entity->id);
And relations:
entity has many comments
entity has many thumbs
thumb has many votes
comment has many votes
And you should tell more specific information about displayName relation...
EDIT:
Entity::
with(['comments' => function($query){
$query->with(['votes', 'displayName']);
}, 'thumbs' => function($query){
$query->with(['votes', 'displayName']);
}, 'displayName'])
->find($entity->id);
EDIT-2:
Entity::
with(['comments' => function($query){
$query->with(['votes' => function($query){
$query->with('displayName');
}, 'displayName']);
}, 'thumbs' => function($query){
$query->with(['votes' => function($query){
$query->with('displayName');
}, 'displayName']);
}, 'displayName'])
->find($entity->id);
Related
I would like to serve my visitors the best results possible when they use our search feature.
To achieve this I would like to interpret the search query.
For example a user searches for 'red beds for kids 120cm'
I would like to interpret it as following:
Category-Filter is "beds" AND "children"
Color-filter is red
Size-filter is 120cm
Are there ready to go tools for Elasticsearch?
Will I need NLP in front of Elasticsearch?
Elasticsearch is pretty powerful on its own and is very much capable of returning the most relevant results to full-text search queries, provided that data is indexed and queried adequately.
Under the hood it always performs text analysis for full-text searches (for fields of type text). A text analyzer consists of a character filter, tokenizer and a token filter.
For instance, synonym token filter can replace kids with children in the user query.
Above that search queries on modern websites are often facilitated via category selectors in the UI, which can easily be implemented with querying keyword fields of Elasticsearch.
It might be enough to model your data correctly and tune its indexing to implement the search you need - and if that is not enough, you can always add some extra layer of NLP-like logic on the client side, like #2ps suggested.
Now let me show a toy example of what you can achieve with a synonym token filter and copy_to feature.
Let's define the mapping
Let's pretend that our products are characterized by the following properties: Category, Color, and Size.LengthCM.
The mapping will look something like:
PUT /my_index
{
"mappings": {
"properties": {
"Category": {
"type": "keyword",
"copy_to": "DescriptionAuto"
},
"Color": {
"type": "keyword",
"copy_to": "DescriptionAuto"
},
"Size": {
"properties": {
"LengthCM": {
"type": "integer",
"copy_to": "DescriptionAuto"
}
}
},
"DescriptionAuto": {
"type": "text",
"analyzer": "MySynonymAnalyzer"
}
}
},
"settings": {
"index": {
"analysis": {
"analyzer": {
"MySynonymAnalyzer": {
"tokenizer": "standard",
"filter": [
"MySynonymFilter"
]
}
},
"filter": {
"MySynonymFilter": {
"type": "synonym",
"lenient": true,
"synonyms": [
"kid, kids => children"
]
}
}
}
}
}
}
Notice that we selected type keyword for the fields Category and Color.
Now, what about these copy_to and synonym?
What will copy_to do?
Every time we send an object for indexing into our index, value of the keyword field Category will be copied to a full-text field DescritpionAuto. This is what copy_to does.
What will synonym do?
To enable synonym we need to define a custom analyzer, see MySynonymAnalyzer which we defined under "settings" above.
Roughly, it will replace every token that matches something on the left of => with the token on the right.
How will the documents look like?
Let's insert a few example documents:
POST /my_index/_doc
{
"Category": [
"beds",
"adult"
],
"Color": "red",
"Size": {
"LengthCM": 150
}
}
POST /my_index/_doc
{
"Category": [
"beds",
"children"
],
"Color": "red",
"Size": {
"LengthCM": 120
}
}
POST /my_index/_doc
{
"Category": [
"couches",
"adult",
"family"
],
"Color": "blue",
"Size": {
"LengthCM": 200
}
}
POST /my_index/_doc
{
"Category": [
"couches",
"adult",
"family"
],
"Color": "red",
"Size": {
"LengthCM": 200
}
}
As you can see, DescriptionAuto is not present in the original documents - though due to copy_to we will be able to query it.
Let's see how.
Performing the search!
Now we can try out our index with a simple query_string query:
POST /my_index/_doc/_search
{
"query": {
"query_string": {
"query": "red beds for kids 120cm",
"default_field": "DescriptionAuto"
}
}
}
The results will look something like the following:
"hits": {
...
"max_score": 2.3611186,
"hits": [
{
...
"_score": 2.3611186,
"_source": {
"Category": [
"beds",
"children"
],
"Color": "red",
"Size": {
"LengthCM": 120
}
}
},
{
...
"_score": 1.0998137,
"_source": {
"Category": [
"beds",
"adult"
],
"Color": "red",
"Size": {
"LengthCM": 150
}
}
},
{
...
"_score": 0.34116736,
"_source": {
"Category": [
"couches",
"adult",
"family"
],
"Color": "red",
"Size": {
"LengthCM": 200
}
}
}
]
}
The document with categories beds and children and color red is on top. And its relevance score is twice bigger than of its follow-up!
How can I check how Elasticsearch interpreted the user's query?
It is easy to do via analyze API:
POST /my_index/_analyze
{
"text": "red bed for kids 120cm",
"analyzer": "MySynonymAnalyzer"
}
{
"tokens": [
{
"token": "red",
"start_offset": 0,
"end_offset": 3,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "bed",
"start_offset": 4,
"end_offset": 7,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "for",
"start_offset": 8,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "children",
"start_offset": 12,
"end_offset": 16,
"type": "SYNONYM",
"position": 3
},
{
"token": "120cm",
"start_offset": 17,
"end_offset": 22,
"type": "<ALPHANUM>",
"position": 4
}
]
}
As you can see, there is no token kids, but there is token children.
On a side note, in this example Elasticsearch wasn't able, though, to parse the size of the bed: token 120cm didn't match to anything, since all sizes are integers, like 120, 150, etc. Another layer of tweaking will be needed to extract 120 from 120cm token.
I hope this gives an idea of what can be achieved with Elasticsearch's built-in text analysis capabilities!
I have this scope defined in my order.json which has relation with branch and customer along with other properties.
"name": "Order",
"properties":{...},
"relations": {...},
"acls": {...},
"scope": {
"include": [
{"relation": "branch", "scope": { "fields": "BranchName" } },
{"relation": "customer", "scope": { "fields": "CustomerName" } }
]
}
This works well as expected in all GET requests with following results
[
{
"OrderDate": "2018-01-12T17:52:21.000Z",
"CustomerId": 39,
"BranchId": 5,
"CustomerRef": "Order by Phone",
...
"CreatedBy": 1,
"id": 1,
"branch": {
"BranchName": "aaaa",
"id": 5
},
"customer": {
"CustomerName": "xxxx",
"id": 39
}
}
]
I was expecting a similar result, however, the response array received after a successful POST request does not include BranchName and CustomerName info from the related models.
Am I doing it correctly? or is there any other way to get back information from related models after a Create/Update operation. I am just trying to avoid another GET request immediately after Create/Update.
You can use the Operation hook after save.
Order.observe('after save', function(ctx, next) {
if (ctx.instance) {
ctx.instance.relatedmodel = someFunctionToGetRelatedModel();
}
next();
});
Whatever is inside the ctx.instance should be included in loopbacks responses.
You just have to figure out how to seamlessly pull the related model details, you want to include.
For example, I wish to get the like count for each post without getting name and Id details of each like.
The likes attribute returned for a call to me/posts?fields=likes.summary(true) would be:
"likes": {
"data": [
{
"id": "aaa",
"name": "bbb"
},
{
"id": "ccc",
"name": "ddd"
},
...
...
],
"summary": {
"total_count": 56,
"can_like": true,
"has_liked": false
}
}
It's the "data" attribute I'd like to suppress coming back due to it (and the same for comments and other fields I'd like to turn off) substantially increasing the bandwidth of data received.
It's the "data" attribute I'd like to suppress coming back due to it (and the same for comments and other fields I'd like to turn off) substantially increasing the bandwidth of data received.
Specify a limit of 0, then you will just get an empty data structure:
me/posts?fields=likes.summary(true).limit(0)
If you enumerate the post id's, you can then get the summary of likes for each post by calling:
/<post-id>/likes?summary=true&fields=total_count
This returns something like:
{
"data": [
{
"id": "<id>"
}
],
"paging": {
"cursors": {
"before": "...",
"after": "..."
}
},
"summary": {
"total_count": 3,
"can_like": true,
"has_liked": false
}
}
If an article has several comments (think thousands over time). Should data.relationships.comments return with a limit?
{
"data": [
{
"type": "articles",
"id": 1,
"attributes": {
"title": "Some title",
},
"relationships": {
"comments": {
"links": {
"related": "https://www.foo.com/api/v1/articles/1/comments"
},
"data": [
{ "type": "comment", "id": "1" }
...
{ "type": "comment", "id": "2000" }
]
}
}
}
],
"included": [
{
"type": "comments",
"id": 1,
"attributes": {
"body": "Lorem ipusm",
}
},
.....
{
"type": "comments",
"id": 2000,
"attributes": {
"body": "Lorem ipusm",
}
},
]
}
This starts to feel concerning, when you think of compound documents (http://jsonapi.org/format/#document-compound-documents). Which means, the included section will list all comments as well, making the JSON payload quite large.
If you want to limit the number of records you get at a time from a long list use pagination (JSON API spec).
I would load the comments separately with store.query (ember docs), like so -
store.query('comments', { author_id: <author_id>, page: 3 });
which will return the relevant subset of comments.
If you don't initially want to make two requests per author, you could include the first 'page' in the authors request as you're doing now.
You may also want to look into an addon like Ember Infinity (untested), which will provide an infinite scrolling list and automatically make pagination requests.
Ember.js doesnt seem to support json objects with dots in the objects attribute names (e.g.):
{ "ns1.id" : 14, "ns2.name" : "mike" };
Is this an omission or am i overlooking something? We have services that we are required to consume that support namespaces in this way.
Handlebars seems to support the above using segment-literal notation (e.g. {{[nd.id]}}). Is that also true of Ember? Is the documentation I have missed?
Thanks!
Yes you can do this. It is compound documents which is used to save HTTP requests, it may be convenient to send related documents along with the requested documents.
In this case, a bit of extra metadata for each relationship can link together the documents. Following example shows use of compound documents:
{
"rels": {
"posts.author": {
"url": "http://example.com/people/{post.author}",
"type": "people"
},
"posts.comments": {
"url": "http://example.com/comments/{post.comments}",
"type": "comments"
}
}
"posts": [{
"id": 1,
"title": "Rails is Omakase",
"rels": {
"author": 9,
"comments": [ 1, 2, 3 ]
}, {
"id": 2,
"title": "The Parley Letter",
"rels": {
"author": 9,
"comments": [ 4, 5 ]
}, {
"id": 1,
"title": "Dependency Injection is Not a Virtue",
"rels": {
"author": 9,
"comments": [ 6 ]
}
}],
"people": [{
"id": 9,
"name": "#d2h"
}],
"comments": [{
"id": 1,
"body": "Mmmmmakase"
}, {
"id": 2,
"body": "I prefer unagi"
}, {
"id": 3,
"body": "What's Omakase?"
}, {
"id": 4,
"body": "Parley is a discussion, especially one between enemies"
}, {
"id": 5,
"body": "The parsley letter"
}, {
"id": 6,
"body": "Dependency Injection is Not a Vice"
}]
}