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.
Related
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'm working in a project in Symfony 3.0.1 that use five databases with DBAL as data access layer. I always worked in Symfony with ORM and I always used the next MVC model:
Data access:
CONTROLLER -> REPOSITORY (the queries goes here) -> ENTITY
Display results:
CONTROLLER -> render($view,$params) -> VIEW
This model allow short and simple controllers, but now I'm using DBAL so I can't use repositories.
The question is:
How can I achieve a similar model by using DBAL? In others words, Where should I put the queries?
Should I use services instead of repositories?
Note: I only use the select statement in that databases.
Thanks in advance!
You don't need an ORM in order to use entities.
Likewise, you do not need Doctrine to be able to build repositories once a repository is a implementation of design pattern:
Repository
Mediates between the domain and data mapping layers using a
collection-like interface for accessing domain objects.
Read more
Even though you can't use Doctrine ORM you still can to design POPO classes against an abstract model class or/and model interface.
You could inject DBAL Connection object for each model/entity via construct or setter method. After creating repo classes is easy. Returning collection objects, hydrating items or using raw arrays is up to you.
Edit #1
I have added a real worl exemple I have used in the past (few years ago), look:
https://github.com/felipsmartins/misc-and-code-snippets/tree/master/php/model-exemple/src/AppBundle/Model
Edit #2
Regarding services, it would much better if there is specialized and well defined models (as opposed to Anemic Models) working together inside a service which coordinates the whole transaction, in this case it would be what we know by Unit of Work (see Unit of Work Pattern)
I have a Symfony2 project and today I'm asked to make it internationalized.
I have several MySQL entities and the new translated contents that I would like to put in a single table containing:
ID | language | content_key | content_translation
Once the _locale is set, I would like to be able to pass this at Entity level, in order to make the Model layer retrieve the content itselves (making a second call to the translation table if that content is one of the translatable one).
I've tried to use Translatable Extension, but since it is a pre-existing database and project, it is not an easy way to pursue.
How can I inject the request (or pass the _locale only) to my Entities?
Thanks a lot,
Andrea
I think you are using Doctrine as ORM with Symfony2?
Then have a look at the Doctrine Extensions. This bundle provides different new behaviors for your entities.
It has also a translatable behavior which is really powerfull.
Integrating the doctrine extensions in Symfony2 is not so complicated.
If you can't use the Doctrine Extensions with your Code/Database, i would try the Doctrine Event Listeners to develop the translatable behavior of your own.
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 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).