Situation: My boss ask me if I can create an entity from a json file. Not populating one entity with values from the json, but creating a new entity with its corresponding file, table and relations.
Could anybody give me some documentation, or an example or an starting point?
Edit1:
My bad, Cerad. I have been developing web apps with symfony (with doctrine as ORM) for about 2 years now. I'm used to its workflow. But i have never considerated this request.
No, you cannot.
This is totally against the principles of how doctrine works internally. (Caches, Proxies etc)
What is even the use case?
Related
I've been provided with a large set of JSONSchema (draft 7) describing a model of incoming messages for a SOAP API.
Based on that i have to create/generate PHP/Doctrine entities to save incoming json messages.
Because that is a large set of files, manual work is not an option. I have to build a generator.
I did some research and there are some php libraries that transform JSONSchema to a PHP model, but not to Doctrine entities.
I know there is an ApiPlatrform project - based on Symfony (i use Symfony as well) that has a schema generator tool to generate entities.
API Platform embraces open web standards (Swagger, JSON-LD, GraphQL, Hydra, HAL, JWT, OAuth, HTTP.) but unfortunately it doesn`t support jsonSchema.
Using this generator would be the perfect solution for me because I could go directly from JSONSchema to Doctrine+Symfony entities.
So now I'm looking for the way to transform JSONSchema to , i think it would be best for my project, to Swagger 3 (i could use Swagger later on for my API).
I didn't find any libraries or documentation that will do that.
There are some libraries that can create PHP classes (so far swaggest is best one i think), but none to create entities.
So now i have to options:
1.JSONSchema to e.g Swagger and use ApiPlatform schema generator to create entities
2.I use Swaggest to create PHP model classes and then somehow i convert it to entities
As a third solution i was thinking that maybe there is a way to transfor JSONSchema to mysql database and then create entities from it (there is a symfony/doctrine generator) for that (here im bit afraid of loosing some relations between tables)
Both solutions are good for me , but I think 1 is best.
So my question is , do you guys know any libraries or can you direct me to how to transform JSONSchema to Swagger ?
My goal is to have a generator that creates a nice and clean PHP Doctrine Entities with all relations and preferrably validation without any additional code (some libraries creates a lot of code on top of PHP classes)
Thanks in advance for any help and suggestions
I am switching over to Symfony for a project that I am working on but I need a little advice on how to structure the files when it comes to models and using doctrine.
I have a custom framework that I use, which in turns uses the MVC model. Pretty much all of my MYSQL database queries are stored in the models and I access them through the controller.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
I have also generated a number of Entities that correspond to my MYSQL database. My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
I'm a little unsure how to structure this.
Thanks
Pretty much all of my MYSQL database queries are stored in the models
That's bad, but I'll mention about it later.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
Queries should be done in either repositories or in some cases in services.
If your query returns entities, then it should be repository for sure.
My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
Entities should be plain PHP objects. They shouldn't depend on anything than other entities. Entities actually doesn't even know anything about database. It's pure object oriented business logic.
Again, all DB queries should be in repositories or services.
I would suggest to go through Symfony Book in first place, to get idea of how "the Symfony way" works.
Symfony is not MVC framework:
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part [...] Symfony2 is an HTTP framework; it is a Request/Response framework.
And it is great. Symfony allows to make your model as you wish without any restrictions. The Doctrine (ORM and/or DBAL) is a separate set of libraries. You can use any other library, or build your own persistence layer abstraction, or work with native SQL through PDO/MySQLi/etc.
Service is just an object that registered in the container and have some dependencies. Services can doing anything. They can represent your model, but it is not a requirement.
Organizing Your Business Logic (The Symfony Best Practices)
Doctrine ORM Best Practices
I need the equivalent method in symfony framework which is there cakephp model->save() method , I do not want to use doctrine orm I just need cakephp like solution to my problem
What you're looking for (i.e. $model->save()) is called Active Record. Doctrine was using it in version 1.x but it does not anymore since version 2.x. You need to find some ORM which does and use it in your Symfony application. As far as I know you can't use Cake's ORM as a standalone component hence you can't inject it in Symfony so you need to find some other Active Record ORM.
You should give Propel a try (and its integration with Symfony - PropelBundle
)
You need to take time to approach Symfony2, you just can't look for an equivalent for every single thing. Learning how to do things "the Symfony" way will be worth in the mid/long run, because the logic is different between those 2 frameworks in many places you won't be able to reason like this for long.
A great place to start is the Symfony book: http://symfony.com/doc/current/index.html
Without Doctrine, you don't have the notion of "model". Then you can only fall back to save (array) data manually using PDO.
I'm just discovering ServiceStack for the first time this weekend and I find it completely amazing. As such, I'm already in the process of converting all of my projects over to it. Then I ran into a small snag.
I can't find any documentation that mentions using OrmLite starting with the database first and then mapping an existing schema into POCOs.
I've found plenty of material on code-first, but nothing on model-first.
Is there a way to use OrmLiite taking a model-first approach?
Thank you.
OrmLite is primarily a code-first ORM, but if you want to start with an existing database you would just create a POCO with properties that maps 1:1 to an existing Table and columns.
It's trivial to infer a POCO manually, but if you want some code-gen tool to help do this, OrmLite includes a couple of T4 scripts you could use instead.
I have just started working on entity framework in an ASP.net application and I was wondering if someone could point in the right direction with respect to best practices. I have some questions in particular which I have listed below.
First of all I am using entity framework 4.0. I already have my database created and so I created a class library and generated the entity model from the database. I had been using Guids generated by the database so I had to modify the ssl to include the attribute StoreGeneratedPattern="Identity". Is there a way to do this automatically or do I have to manually edit the ssl everytime I update the database and the model? (For those of you know are facing a problem with guids or want to know why I am doing this.. this is a clear article on the problem with auto generated GUIDs)
I was planning on using a single file in the class library to hold all the database queries. Is this good practice? How would I ensure different programmers dont rewrite the same queries over and over?
I was planning on using a unique context per method. Is this the right way to go? I read through Rick Strahl's post on context lifetime management. But I am still not sure if a unique context per method is the right way to go.
Can I have my database queries as static methods since they do not make use of any instance variables?
If I use a unique context per method as mentioned in 3 and I wish to modify an entity object returned by one context what would be the best practice? Do I use the attach functionality to attach the object to a new context and save the changes ? I havent tried this but I have read a couple of articles and it seems a bit straightforward but wanted to know if there are any alternatives to this.
If you any suggestions on how you use Entity Framework in an ASP.net application I definitely could use help. This is my first ASP.net/Entity framework application so any tips will help
This was issue in initial version of VS 2010. In some cases this should already work correctly once you have VS 2010 SP1 installed. If it doesn't install this KB.
You can easily get huge class with a lot of static methods. Try to use some separation by the entity type you are querying. You will never fully ensure that another programmer will not create the same query again. This is about correct query naming following same naming policy, documentation and communication among programmers.
Unique context "per method" is usually not needed. In most cases you should be happy with unique context per logical (business) transaction - in case of web application logical operation is in most cases single request processing = one context per request.
If you pass context instance to your queries the answer is yes. Once you don't create them as static and they will take context instance from their class instance you will be very close to repository pattern.
This is exactly problem with context per method and it is hard to solve because to make this work you must first detach entity from the first context and attach it to the second context. If your entity has also related entities loaded all these relations will be nulled during detaching (unless you use deep clone instead of detaching = creating second instance of the entity).