Wit.ai doesn't understand entities but on_off instead? - wit.ai

I have defined an entity "team" with value "FC Barcelona" and the alias "Barcelona". The language of the app is set to German. Any idea why "Barcelona" is recognized as a wit/on_off entity? Actually for every sentence (doesn't matter what) I enter, the wit/on_off entity is recognized with some random word as the value.
A strange thing is also that I have the wit/on_off entity twice there.
That's an app that I imported from the export of another app. Can I delete one on_off? But which one?

You can simple delete the mistakenly recognized on_off entity and add your team entity. After some samples it wit.ai should improve the recognition.

Related

Elm project scaling: separating Messages/Updates

I am trying to separate files in an Elm project, as keeping everything in global Model, Messages, etc. would be just a mess.
Here is how I tried it so far:
So, there are some global files, and then Header has its own files. However I keep getting error, when importing Header.View into my global View:
The 1st and 2nd entries in this list are different types of values.
Which kind of makes sense:
The 1st entry has this type:
Html Header.Messages.Msg
But the 2nd is:
Html Msg
So, my question is whether all the messages (from all my modules, like Header) needs to be combined somehow in global Messages.elm? Or there is a better way of doing this?
My advice would be to keep messages and update in 1 file until that feels uncomfortable (for you to decide how many lines of code that means - see Evan's Elm Europe talk for more on the modules flow). When you want to break something out, define a new message in Main
type Msg
= HeaderMsg Header.Msg
| ....
Then use Cmd.map HeaderMsg in your update function and Html.map HeaderMsg in your view function to connect up your sub-components

Is OOP really helping?

I am trying to create a simple module in Drupal 8 and it looks like what was really easy in Drupal 7 is now unbelievably complicated. It can be done with help of StackOverflow and Google, however, one example:
Getting field values from node like this:
'name' => $node->get('title')->getValue(),
'body' => $node->get('body')->getValue(),
'image' => file_create_url($node->field_fotografia->entity->getFileUri()),
Why is the way of getting image field different from the title and body? How do I know what way to use and how will I know in future if there is any other way for other type of field?
the logic is quite simple
$node->get('body')->getValue();
means: get property value of field "body"
D7 equivalent is
$node['body'][$language][$index]['value];
which is straigh forward
now the other example
$node->field_fotografia->entity->getFileUri()
means: get property uri of entity stored in field "field_fotografia" since the image is not a property value but a separate entity; actualy I believe that $node->get('field_fotografia')->getValue() returns the image id which make sense. Same model applies for all entity references (multifield, paragraphs, other nodes, etc).

Symfony3 Doctrine2 Column cannot be null

[PROBLEM SOLVED]
Hey folks I need your help on a symfony project.
I have two entities, "article" and "image", article can have several images so I made a relationship OneToMany on the article side and ManyToOne on the image side. Doctrine generates for me an "article_id" column on the image table.
I made a form to create an article with one or more images... however when I execute it I have an error that is thrown :
An exception occurred while executing 'INSERT INTO image (url, alt, article_id) VALUES (?,?,?) 'with params ["jpeg", "untitled.jpg", null]: SQLSTATE [23000]: Integrity constraint violation: 1048 Column' article_id 'can not be null.
When I look to the profiler logs debug, I can see that I have an "INSERT INTO article[...]" (so the article is created with an ID ?) and just after this I have the famous "INSERT INTO image[...]" where the error occurs.
Thank you for your help.
EDIT In bold you will find the lines I added to solve this problem.
I added into the ArticleType form, in the images collection options this :
'by_reference' => false
And I added to the addImage method into the Article entity this :
$image->setArticle($this);
$this->images->add($image);
This is a very common question but surprisingly difficult to search for. In fact the first ten or so search results had incorrect answers.
In any event, you need to make sure that image is linked to the article.
class Article
public function addImage($image) {
$this->images[] = $image;
$image->setArticle($this); // ADD THIS
I think #Cerad's answer is very wrong, although I can't blame him because OP hasn't posted enough code, don't be shy with it, we're here to help. It also helps to briefly mention if you're just starting out (as I suspect you are) as it will help us gauge whether its a novice problem or something deeper.
Since I'm assuming it's a novice problem here is the novice solution.
With they way you've mapped (which I believe is correct) you are basically telling Doctrine to Tell your RDBMS (MySql/MariaDB/PostgreSQL) that an article CAN have many images, but an image MUST belong to an article.
This means that if you attempt to save an image without specifying the owning article, it will throw an error.
This is what I think you are doing evident in the line
(url, alt, article_id) VALUES (?,?,?) 'with params ["jpeg", "untitled.jpg", null]
the value "null" is where the issue is coming about because you are not specifying the owning article.
You have 2 options
1.) When saving image, if you have the article object at hand just do
$image->setArticle($article);
2.) When saving the image, if you have the article_id at hand just do
$image->setArticle($em->getReference('AppBundle\Entity\Articles', $article_id));
You must follow one of the above when saving an image directly.
My general experience has been that Doctrine does a really good job of generating entities from command line that you really don't need to change much unless adding some advanced functionality like second_level_cache or MySQL point type.
Cheers.
The problem is that when you submit your form, the first image is attached to the article but the others are not, so you get an SQL error.
You have to do a "foreach loop" for every image and attched the article to each one.
Look here at the addAction function
https://github.com/ismail1432/TheGoodLoc/blob/master/Symfony/src/VTC/AnnonceBundle/Controller/AdvertController.php

Wit.ai - 'Thank you’ being detected as search query always. Even after training it for entity

I have created a new app in wit.ai. In stories, I have created entity with different intents. Here I used 'Thank you' as a different intent. But when I send 'Thank you' to wit, it considers it as a search query instead of the entity which I created. I trained it for that entity in the 'Understanding tab. But still it is considering it as a search query. Like that for some other intent also, it considers as a search query only. What shall I do to make the 'Thank you' string as an entity instead of search query?
Thanks.
Are you using trait for "thank you" or freetext, keywords?
From Wit docs:
" Only trait entities (like typically intent) have their value
influence the action prediction. For non-trait entities, the value is
ignored with regards to action prediction."
Also you can add restrictions in Actions tab to prevent undesirable function callings, if needed.

Ruby on Rails 3: rails_admin + puret?

Did someone try to integrate puret into rails_admin? I can't make a language switch to edit different translations :(
Changing I18n.locale forces whole rails_admin to use specified locale.
Now I got the solution. The two can work together well. In short:
Delete the pureted column(s) in your model
If you have the column pureted still in your model, rails form helper will bypass puret. That is, if a model called Post has a field called contents to be i18ned, the table posts SHOULD NOT have the column contents.
Actually we should use globalize3 instead. With this you do not need to remove the original column. And puret doens't support nested attributes assignment. globalize3 works very well.