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.
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.
Recently I began to study SF2 but there are some doubts which I'd like to solve:
Let's say that I have a lot (more than 100) of Models which extend one generic model(Entity). Each model has unique functions (rules for parsing content from model source), what is the best way to organize it?
In ZF1 I would create Model/ModelType/ModelName.php file for every model which need customization, in SF2 I'm not sure what kind of entity should I use: One service container which calls entities and call their custom functions (implemented through interface), or maybe one huge Service which has different functions for every single model?
Thanks in advance.
If parsing functions based only on current entity state (use only entity property) it's better to use entity method. Entity aslo can implement some interface, e.g. ParsableInterface.
If paring function need to use another entities it's better to use standalone services handle parsing
I am confused at when to create a new bundle or when just to create a new controller and CRUD in Symfony 2. If I have an entity that has joining tables to other entities should that all be in the same bundle.
An example would be I have a user bundle and I wanted users to be able to like videos in the system. There for the user and a video will be linked in a joining table.
Before I started the project I would have said that I would need to create a video bundle and a user bundle, but if they both need to reference each other should they be in the same bundle?
And if the answer is that they should be in separate bundles what is the best practice to reference them in either of their views and controllers?
I'll go for packing common features in the same bundle. It's quite hard to understand when you start learning Symfony 2, I know. Consider, for example, FOSUserBundle: it defines common and reusable code for CRUD operations on users, groups, authentication and so on.
As a starting point you should learn How to Define Relationships with Abstract Classes and Interfaces and Doctrine Inheritance Mapping (mapped superclasses are very useful for extending your bundle, with some limitations).
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.
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).