How can Dialogflow get a specific string (login/id) in a phrase? I thought to create an Entity called "login" with all the logins as "synonyms".
Is it the best approach?
PS: I have more than 1500 logins/id and Dialogflow allows up to 200.
Thanks
According to the example in your comment, it seems you need to get the person's name.
Dialogflow offers a system Entity called #sys.person
#sys.person: Common given names, last names or their combinations
You can also extend system entities if you want to add values that do not exist:
Extend a system entity while annotating a training phrase:
From the intent page's training phrase section, you can extend a system entity while annotating a training phrase. If you manually annotate a training phrase part with an extendable system entity that does not include the selected value, you will be prompted to add this value to the system entity.
Extend a system entity from the entities page
From the entities page, you can extend a system entity by following
these steps:
Create an entity.
Use the name of the system entity you want to extend. For example: sys.color.
Provide entity entries using the values you want to extend the entity with.
If you are using the API to extend system entities, create system
entity extensions similar to how you create developer entities.
Provide the name of the system entity you wish to extend, and provide
the values you want to extend it with. If you attempt to extend a
system entity that is not extendable, you will receive an err
Related
I couldn't understand the difference between Embedded Entity and Entity using ancestor path on GCP Datastore.
I could understand following things.
By using ancestor path, it can manage entities as different kind, but there's writing 1 times/sec limit.
Ancestor path makes Strong Consistency
But these things are same as using embedded entity.
So I'm confusing how to use embedded entity and ancestor path appropriately.
Now I'm developing a model for form like Google Form.
It can be added items freely, so I'm thinking using embedded entity named Item or create kind named Item and use Ancestor path for Form class.
The embedded "entity" is not a real entity, it's just a property inside the "container" entity in which it is embedded. From Embedded entities (emphasis mine):
You may sometimes find it convenient to embed one entity as a
property of another entity.
You still have the 1 write/sec limit for that "container" entity. And you cannot update just the embedded "entity", you have to update the entire "container" entity.
The embedded entity may appear strongly consistent, but only in the sense that it's consistent with the other data in the "container" entity (nothing special here, the same is true for any property inside an entity). It is still eventually consistent when it comes to making queries using its values. And you cannot make such queries inside transactions.
Entities tied by ancestry on the other hand are real, distinct entities, all being placed inside the same entity group. The entire entity group is subject to the 1 write/sec limit. Ancestor queries have a scope limited to the respective entity group, are strongly consistent can be done inside transactions.
If strong consistency is what you're after then you have to use the datastore ancestry to tie the respective entities together.
Otherwise you can use either the embedded entities or simply plain entities of a different kind and establish the relationships between entities using Key properties. See also E-commerce Product Categories in Google App Engine (Python)
I'm having problems figuring out the best way to model the following relationship with Django.
I currently have a Site model as the main model that everything else attaches to. A Site is made of two basic building blocks: ModuleSlots and modules. A ModuleSlot is something that a module (which I'll describe in just a second) can be attached to.
Then I have a model called ModuleBase, which is the base model for modules that can be attached to site's moduleslots. A module is a self-contained piece of site that is itself functional – it doesn't know anything about the outside world. The ModuleBase model is meant to be inherited to create new modules – example modules are a Poll module and Content module. The point is, I want to have the ability to define new kinds of modules in the future, so that's why I went for the base-class approach. The picture below may better describe what I just wrote.
Now, I want to bring time into this scheme – ModuleSlot's content should be timeable, meaning that the module AND the attached poll/content/etc. should be able to change at the same, pre-defined time. For example, let's say that a ModuleSlot is currently tied to Content module. I want the ModuleSlot to change to point to a Poll module and show a spesific Poll. This all should happend automatically at spesific time.
How should I present this kind of relationship? I'be been giving this some though and this is what I have so far: I think I should create some kind of GenericContent model that is then inherited by individual content types that the modules define, eg. Poll of the PollModule would inherit from GenericContent, and Content of the ContentModule would do the same. I should also introduce TimeSpan for the ModuleSlot. Then, in the backend, I could check every minute if a ModuleSlot needs an update, and do the update if the module and attached content should be changed. What do you guys think? The messy picture below (may) describe the relationships described.
I'm not sure if the inheritance is the correct way to go here (GenericContent). I could also just store id of the Poll/Content/etc. in the ModuleSlot, as all my id's are the same type – since I know the module that is attached to a ModuleSlot, I can ask the Module for the content for the given id.
I am using EMF to allow users to create instances of a particular type of model.
An instance of a model can have 0-* Things but I'd like to be able to predefine the available Things that the user can add to the instance so that they can't just create their own.
How would I go about creating the Things using the ecore model?
If a Thing was just a String then it would be fine - I could use Enums. But a Thing is a type of it's own and consists of other stuff (like a name, version etc.) and I don't know how to give a predefined set of these to the user to choose.
Any ideas?
You have the possibility to use constraints or *EOperation*s.
For a better usability you should use a own dialog implementation. An example of a own implementation with given choices you can find here:
How can I control which instances are available as choices when editing a property in the properties view?
You should also implement a own property source to support the properties editor:
Recipe: Create your own property editor in a generated application
I'm working on a Symfony2/Doctrine2 project which handles 2 databases on MSSqlServer.
The first database A_db has a table forms and the second one B_db has people. All my entities are defined with annotations.
I need to get all forms from forms related to people as I will explain in following lines.
I've spent some time reading related answered questions:
Most likely what I need Using EntityManager inside Doctrine 2.0
entities!
Of course, a service! Doctrine2 Best Practice, Should Entities use Services?
Services/Repositories/Whatever Using the Data Mapper Pattern, Should the Entities (Domain Objects) know about the Mapper?
So I decided that a service might be the best way to handle my needs. But it makes no clear to me how actually get this done. I mean, where to put my service class, how to define it in config.yml, how into people entity...
My wish is to set up a full service (assuming its the best implementation) to perform something like:
foreach($onePeple->getForms() as $form) {/* some code with form */}
In case service implementation for doctrine is not the best practice, then what would it be and how can I make it work?
What you're asking there is possible using the entities alone - so long as you define a relationship such as this on the Form entity:
/**
* #OneToMany(targetEntity="Form", mappedBy="User")
*/
protected $Forms;
And on the User entity:
/**
* #ManyToOne(targetEntity="User", inversedBy="Forms")
*/
protected $User;
Then you can simply load a User entity (through a service, a repository or however you wish) and then access all the forms belonging to that user through $userObj->Forms (if using magic __get on your entities, if not then using a getter method, again down to your preference). Forms is an instance of an object implementing the Doctrine\Common\Collections\Collection interface (since it is a to-many relationship) which is iterable using a foreach.
In projects I have worked on using Doctrine2, we typically use our services for getting, saving and deleting entities, along with listing entities of a type (we call them index methods). This way you can tie in extra functionality required in saving, such as updating other entities which are closely associated and so on. These services are tied to the persistence layer and contain a reference to the entity manager, leaving the entities themselves isolated and testable.
We've also had the argument of whether to put this kind of logic in repositories or services, but that is more a case of personal preference and/or project requirements.
One thing to note - services you build are not going to be linked into Doctrine. It is unaware of your service layer (it's just some userland code) so it is up to you to link it in a meaningful and clean manner. Essentially you'd want something where you could pass the entity manager in through the constructor of the service and have some kind of base service class capable of operating on all entities, which could then be extended with special logic on a per-entity basis. Repositories, however, are intrinsically linked into Doctrine, so if that is what you want then it might be the best solution. We tended to use services as they are then purely related to implementing the business rules and so on, leaving the repositories to be used as a component of the persistence layer.
I've got 2 applications (lets call them AppA and AppB) communicating with each other.
AppA is sending objects to AppB.
There could be different objects and AppB does not support every object.
An object could be a Model (think of a game, where models are vehicles, houses, persons etc).
There could be different AppBs. Each supporting another base of objects.
E.g. there could be an AppB which just supports vehicle-models. Another AppB just supports specific airplane-models.
The current case is the following:
There is a BasicModel which has a position and an orientation.
If another user wants extra attributes, he inherits an ExpandedModel. And adds e.g. an attribute Color.
Now every user who needs additional attributes inherits from a more general model. After a while there is a VehicleModel which could activate windshield-wipers, an AircraftModel which could have landing lights or a PersonModel which could wave goodbye when a certain boolean is set to true.
The AppB always needs to be customized if it should support a new Model.
This approach has a big disadvantage: It's getting extremely complex after a few inheritations. Perhaps there are redundancies like an ExpandedAircraftModel which could use windschield-wipers too.
Another approach:
I create just one Model-class which has an attribute-list. The most easy implementation would be a std::map where the Key is the attribute-name and the Value is the attribute-value.
The user could now enter as much information as he wants. If he wants to use a windshieldwiper he just adds a "windshieldwiper - ON"-pair.
If AppB supports windshieldwipers it just looks if there is such an attribute in the list and reads the related value.
A developer of AppB needs to document well what attributes he supports. Every developer has to check if the specific attribute is already existing and how it is called (e.g. one developer could name his attribute windshieldwiper and another calls it windshield-wiper)
This could get extremely complex too and the only thing a user can relate to is the documentation or a specific standard-specification which has to be kept at a central space.
Finally, the question:
Which approach is better?
Did you see any additional disadvantages?
Is there a third approach which should be used instead of these two?
Just for a comparison, Google's Protocol Buffers uses a combination of both but leans hard toward your second example.
If you have distinctly different data that needs to be sent over the channel, you use the tool to generate a derivitive of the "message" class, but each message can contain other messages, and you can nest message definitions in themselves. When a message is sent out, the receiver checks the fields to determine what type of message it is and what fields are contained within.
The downside is that your code becomes overly verbose very quickly, as you can't really use inheritance to automate the process of acting on an incoming message, but the upside is that your protocol messages stay highly organized and easy to DEBUG since you're using a reflexive attribute list of sorts.