I`m working on my own Extension that will include a annotation.
I want to extend my entities by using the annotation. The entities should extended by some extra fields. I do that by listening the metaclassloaded Event.
But doctrine throws an exception because the entities don't have the properties. Is it possible to add them programmatically?
Related
I'm work on Dynamics 365 online V9. I have encounted a problem when creating a new entity with related entity.
I have custom entities new_quote and new_quotedetail, with 1-N Relationship. I have a plugin on entity new_quotedetail on preCreate event that will check if the target contains the key "new_quoteid", otherwise il will block the creation.
the problem is that I want to create new_quote with its all details in the same time, so I use entity.RelatedEntities to create them. but it look like the child detail entity target doesn't contain the new_quoteid, is it normal?
I have tried to register the plugin in post-create event but still have the problem
Thanks
Song
Field is populated by associate message, if you are using the create related in one operation having logic to check on related entity create message wont work because like you say field not populated at that time. Move child record creation into second message and your plugin should work as is.
You will not be able to do this at one go.
Reason been your child entity has plugin on create which checks and restrict creation unless you have primary entity created.
I will suggest separate logic in 2 calls I.e first create parent entity and after create of parent then fire plugin to create child entity.
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
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 am quite new to Doctrine 2. I am wondering if there is an easy way / what the beast way is to include fields such as date_created, date_modified, author_id etc across all of my entities - or do I need to paste these fields into each yaml file. Would be great to specify these globally so that new fields can be easily added etc.
You can use a mapped superclass - Essentially you would create a superclass where you put your shared properties and add mappings to it, then have your actual entity classes inherit it.
See manual section Inheritance Mapping: Mapped superclasses
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.