I'm trying to make some kind of "reusable" base controller in Symfony 2. Given the name of an entity, is it possible to read the schema of that entity? That is, a list of the entity's fields with the name and the type of each one.
This is in order to automatically generate the inputs in an admin panel and other similar operations.
SensioGeneratorBundle provides CRUD generation capabilities.
Its source code is available on GitHub.
Its documentation is well written; you should probably read it before making your decision.
This bundle can generate a CRUD controller based on a Doctrine entity. Once your application is set up, run the following command:
php app/console generate:doctrine:crud
It will generate forms, controllers and views.
Generated classes are easy to extend.
Related
I am running a Symfony 3.4 based web service using Doctrine to manage and persist the different data entities.
Now I am trying to implement a method which transfers older, abandoned user accounts to another database which acts as archive.
Regarding to the Symfony docs it should be no problem to configure Doctrine to manage different database connections and entity managers.
However I do not completely understand the process on how to setup this use case:
Assume the Symfony project has different data entities DataEntity1, DataEntity2, etc. and different infrastructure entities Infrastructure1, etc..
How to tell Doctrine to initialize the archive DB with the data entities only?
How to move the entities between the DBs? Is loading them from entity manager 1 and persisting them in entity manger 2 the correct way?
Is there any best practice on how to do this?
If I understand your question correctly, you should use the prefix option for the mapping configuration.
prefix
A common namespace prefix that all entities of this mapping share.
This prefix should never conflict with prefixes of other defined
mappings otherwise some of your entities cannot be found by Doctrine.
This option defaults to the bundle namespace + Entity, for example for
an application bundle called AcmeHelloBundle prefix would be
Acme\HelloBundle\Entity.
Have a look at https://symfony.com/doc/3.4/reference/configuration/doctrine.html it shoul help you.
To move the entities between the two DBs, you should have two entity managers and use the correct one to persist olders accounts.
Hope this helps.
We have different symfony4 projects (readonly APIs) which uses the same database.
In every project we use, for example, the User Entity and the Groups Entity.
So, if we change the database (eg. add a new field), we have to change all the entities in all our projects. How can we solve this problem?
Should we create a Entity Bundle and install it with composer to every project? Or is there another solution?
Usually the best approach for implementing reusable code is to create bundles. That way you can easily reuse them and update them.
I have a legacy application that was using Xaraya to manage user content that I am trying to replace with a rewrite using Symfony/Sonata to manage users and/or content.
For whatever reason, previous developers managed this with two different databases (MySQL for Xaraya, and SQL Server for other things, including authenticating users).
I am trying to create Entity mappings such that the users/groups from SonataUserBundle (which extends FOSUserBundle) use the entity manager associated with the login database connection, and this works for logging into the admin site itself, but blows up when it tries to hydrate objects that have associations to the User entity.
It appears that Doctrine does not try to find the entity manager associated with an entity when hydrating an object's associations.
My question is this: it it possible to make Doctrine hydrate objects using the entity manager for an entity instead of assuming it's mapped to the current entity manager, and if not, is there any form of a clean code work-around for it?
Thanks.
(Note: The method of using the "databasename.tablename" syntax in the query that I have seen mentioned elsewhere will not work for my use case.)
I would like to override the Entities, Form ect.. in Symfony 2 to create my own functions. This to don't loose my code when i re-generate my Model from my database.
It was easy in symfony 1.4 because symfony generate the model and all the override files but i don't understand how to in Symfony 2
Many thanks
Symfony 2 uses mapper files or anotations to generates entites base setters/getters. And it creates entities backup files. So it's safe to create own logic in enties, but it's better keep entities as light as possible and move logic to services/manages.
I'm working on a Symfony 1.4 project with Doctrine 1.x, and functionality that merits using a Doctrie_View (as an interface for native MySQL Views).
As I understand it, the View (as in DB View as opposed to the View in MVC) has to be created wth Doctrine so that Doctrine can maintain the association between the View and the original Model from which it's derived.
In an ideal world, I'd like to have the View created as part of the symfony doctrine:build --db task. The sensible way to do this would be to use the observer pattern and Symfony's Event Dispatcher, however, the list of Built In-Events doesn't seem to offer an event for when the database schema is built.
So, what's the best way to have a Doctrine View created when the schema is built?
Or perhaps, if that's not an option, check if a View doesn't exist and then create it as part of ProjectConfiguration::configureDoctrine()?
doctrine:build-sql
I think you should rather look at the doctrine:build-sql task which builds the sql instructions from the model definition.
If you look at the sfDoctrineBuildSqlTask class you'll notice it's rather simple. It really only calls the doctrine cli. If you want to hook into it you should check the Doctrine events rather than symfony.
migrations
What you could also do is creating your view in doctrine migrations. Whenever you need to change your view you'll create another migration (removing old and creating new view).