I recently got to know the Sylius project and was trying to reuse its components in a separate project (study only).
My goal was to test if I can use the sylius components in a separate project. Only a few components.
Following the documentation (http://sylius-older.readthedocs.io/en/latest/components/Order/basic_usage.html), I was able to install the components and use their classes, but how do I do the database tables?
I installed the doctrine and tried to map the classes, but I could not.
I was thinking of creating the migration (doctrine or eloquent) for each table and doing the actions (CRUD).
Thank you so much guys.
Assuming you have installed the OrderBundle using Composer you will probably have to tell Doctrine where to read the entity mapping. In case of Sylius' OrderBundle they are stored as xml files in Resources/config/doctrine/models, e.g. Order.orm.xml. If you look at the sample configuration in the DoctrineBundle-recipe you can find a reference for a manual mapping. In your case it probably should look something like this:
# app/config/config.yml (in Symfony 3.4)
# config/packages/doctrine.yaml (in Symfony 4)
doctrine:
dbal:
...
orm:
mappings:
SyliusOrderBundle:
is_bundle: false
type: xml
dir: '%kernel.project_dir%/../vendor/sylius/order-bundle/Resources/config/doctrine/models'
prefix: 'Sylius\Component\Order\Model'
alias: SyliusOrder
You might have to tweak this, e.g. if you have a Symfony 4 app, but with this you should be able to create the appropriate schema using the default Doctrine commands. You might also have to adjust auto_mapping under doctrine.orm and possibly manually map your own entities if you do this.
I've just started working with Symfony and have run into a problem that I'm having a hard time tracking down information about.
I'm trying to create a bundle which has its own configuration file, e.g. configuration for doctrine connections.
All documentation I've found have never mentioned of showed how this can be set. Is it possible?
What I want to solve:
I have a bundle which when installed should handle connection to a secondary database table without any configuration needed from the main application in which the bundle has been integrated. Ultimately the configuration in the bundle should be override-able from the main application.
The bundle should be in the lack for a better work "self contained".
I've found documenation about bundle configuration. But all I've seen mentioned there is if one would like to configure the bundle and not interaction with other components (might have missed something).
tl;dr I want to have a config (e.g. AppBundle/Resources/Config/config.yml) file inside a bundle which can configure things like doctrine.
What i've tried
I've tried placing the configuration inside a config.yml file located in Resources/Config/. But I guess the file is never read.
I think it is not good idea to put something related to configuration right inside your bundle and ruin it's reusability by doing such thing. As far as I understood your task what your really need is to configure second entity manager to manage entities from secondary database when you need them. Same problem and its solution are described in following question: Doctrine 2 - Multiple databases configuration and use
Hope that will help!
Suppose I have an entity.
This is going to be used in two bundles. But I want bundles to be as indepenent as they could.
Where should I place my entity? In another bundle?
This seems like a good place, since my two main bundles are big enough, and when I want to use them in another project (which happened and happens for me), I have to copy both bundles. Not so good for me.
If I put entity in another light bundle, then I have to move a big bundle and a small bundle. Good, but is there a better way in symfony to do this?
I am working on an application that needs to support the multi-tenant model. I am using the symfony2 php framework and doctrine2.
I'm not sure the best way to go about architecting this requirement. Does Symfony's ACL functionality provide a part of the solution?
What recommendations or ideas could you provide? Are there any sample symfony2 applications or open source applications that are available which have implemented this strategy?
My first thought is to use a tenant_id column in all the tables and have this relate to the account object in the application. I'm not sure though if ACL is supposed to take care of what i'm wanting to do, or if your still responsible for all of the queries against your objects so they don't return un-authorized data.
If I wasn't using Doctrine, it might be easy to say just append Where tenant_id = #accountid to each query, but i'm not sure that is the right approach here.
Thanks
We've been doing this for some time now (although not with symfony and doctrine but the problems remain the same)
- we started with one huge database and implemented a 'environment identifier' per row in each of the tables. This way schema migrations were easy: all the code was unified thus a schema change was a single change to code and schema.
This however lead to problems with speed (large tables), agility (moving/backuping etc large datasets is alot more intensive than alot of smaller ones) and of course more easily breakable environments since a single failure will pull down every dataset in the system...
We then switched to multiple databases; each environment its own schema. By utilizing the migrations provided with Doctrine (1 in our case) we're able to quickly update the entire app or just a single environment. Also the ability to move specific changes between tentants allows for better precision in speed and optimization.
My advice would be: create a single core which is extended into the different tenants and keep the local customized database configuration per tentant. (in a app.ini-like structure)
i.e.
/
apps/
tentant1/
models/ <--- specific to the tenant
libraries/ <--- specific to the tenant
config/
app.ini <--- specific configuration
tentant2/
/**/ etc
core/
models/ <--- system wide models
libraries/ <--- system wide libraries (i.e. doctrine)
core.ini <--- system wide configuration
This could keep everything organized. We are even going as far as having the comeplete structure of core available per tentant. Thus being able to override every aspect of the 'core' specific to the tenant.
We do this with one of our main solutions at work, and it's certainly possible. We use Symfony2's bundles to create a "base" bundle which is then extended by other per-client bundles.
That said, we're looking at moving away from doing things this way in the future. The decision to go multi-tenant was not the right one for us, as many of our clients are uncomfortable with their data being in the same database tables as everyone else's data. This is completely aside from the potential issues of slow performance as the tables grow.
We've also found that Doctrine 2 has some pretty serious issues unless it's kept well under control. Whilst this may be a side effect of poorly structured code and database logic, I feel it's a bit of a hole for an ORM to be able to get to the point where it throws a fatal error because it's used too much memory - particularly when the only reason it's using so much memory is because it's batching up SQL queries so that they can be made "more efficient".
This is purely my opinion, of course :) What doesn't work for us may well work for you, but I do feel you'd be better off keeping separate databases per-client, even if they're all stored on the same server.
I think that, To manage multi-tenant multi-database with symfony 2/3.
We can config auto_mapping: false for ORM of doctrine.
file: config.yml
doctrine:
dbal:
default_connection: master
connections:
master:
driver: pdo_mysql
host: '%master_database_host%'
port: '%master_database_port%'
dbname: '%master_database_name%'
user: '%master_database_user%'
password: '%master_database_password%'
charset: UTF8
tenant:
driver: pdo_mysql
host: '%tenant_database_host%'
port: '%tenant_database_port%'
dbname: '%tenant_database_name%'
user: '%tenant_database_user%'
password: '%tenant_database_password%'
charset: UTF8
orm:
default_entity_manager: master
auto_generate_proxy_classes: "%kernel.debug%"
entity_managers:
master:
connection: master
auto_mapping: false
mappings:
AppBundle:
type: yml
dir: Resources/master/config/doctrine
tenant:
connection: tenant
auto_mapping: false
mappings:
AppBundle:
type: yml
dir: Resources/tenant/config/doctrine
After that, we cannot handle connection of each tenant by override connection info in request_listener like article: http://mohdhallal.github.io/blog/2014/09/12/handling-multiple-entity-managers-in-doctrine-the-smart-way/
I hope that, this practice can help someone working with multi-tenant
Regards,
Vuong Nguyen
BEST builds different notices in different mind. Please be more specific to ask questions. One of the way to develop multi-tenant system is to put a common primary key in all the tables to build the relationship. The type and nature of the primary key is dependable project wise.
Why not to try different databases for each client to keep the data separated and give them unique entry point to your app. Ex: http://client1.project.net which with the routing system will map to client1 database.The bad side of this: more complex database changes, because all databases for each client needs to be upgraded.
This is something I've been trying to figure out as well. Best I could come up with (not in an implementation yet, but in theory) is this: give each tenant their own database login and use views to keep them from seeing other people's data.
I ran across this link that describes a way of doing this for just plain old MySQL (not with Symfony/Doctrine).
Basically, you have your actual database tables, but each table has a column that stores the name of the database user that made the row. Views are then created that always filter by this column so whenever a user logs in to the database (via an admin tool or even connecting through Symfony/Doctrine), they are only ever returned records directly associated with them. This allows you to keep the data "separate", but still in one database. When pulling data (say for an entity in Symfony), you are pulling data from a filtered view vs. the actual database table.
Now, this solution isn't exactly Symfony/Doctrine friendly. I was able to get a very quick and rudimentary test of this running before; Doctrine was able to use the database views just fine (it could insert, edit, and delete entries from a view no problem). However, when doing things like creating/updating schema, it's not fun. Granted, Symfony/Doctrine seems pretty extensible, so I'm confident there is a way to have it automated, but this kind of setup isn't supported out-of-the-box. Doctrine would need to be told to update the tables, always append the column for holding the username to the entity tables it creates, update the views as well, etc. (You would also need a way to load up the proper database config in your Symfony app, mainly the different logins as the server and other stuff would be the same.) But, if this can be overcome, your app itself could run these multiple tenants completely "ignorant" of the fact that other people's data is sitting in the database.
I am new to ORM and I am really keen to learn it. I successfully managed to install all classes and configurations for Doctrine 2.1 with Zend 1.11.x by following this tutorial.
http://www.zendcasts.com/unit-testing-doctrine-2-entities/2011/02/ Which uses Bisna plugin and doctrine scripts.
Now my problem is he is clearly explaining how to create entities and tables through doctrine classes but do not explain how to auto generate the proxies and repo classes from already existing database which helps me to select, insert and update. I always create my databases using MySQL Workbench.
I also followed the below tutorial as well
http://www.zend.com/en/webinar/Framework/70170000000bSrG-webinar-zf-v-1-doctrine-v-2-20101214.flv
My database is so complex with relationship flowing across every possible way. If I follow the steps which is explained in these tutorials I will never complete my project. Can any one please explain how to start using Doctrine after configuration. Considering I already have a database and my Model folders are empty. I have my folder sructure as below.
C:/zf/library/Doctrine
C:/zf/library/Symfony
C:/zf/library/ZC -- (my model which should contain the proxies and repo of Doctrine. At the moment it contains nothing.)
C:/zf/library/Zend
C:/zf/scripts/doctrine.php
Please help me!
I posted this same post yesterday and no one replied to my post. Please let me know if you need anymore information from me.
Thank you,
Karthik
According to Doctrine you should create your entities first yourself and then create your database schema from these entities.
But because you already have a database you probably don't want that. It is possible to convert your database to Doctrine2 entities in PHP, XML or Yaml.
You should take a closer look at the commandline tools Doctrine offers with the Bisna glue because there you can generate a lot of stuff.
To generate your entities FROM your database consider the following command:
php doctrine.php orm:convert-mapping --from-database php ../library/Application/Entity
You can also define the namespace and a base class which your entities have to extends with: --namespace=namespace and --extends=class.
Doctrine2 warns you to convert your database to entities because not everything could be auto detected or supported. For instance ENUM datatypes are not supported by default in Doctrine2 so converting your database will raise an error.
It's a good idea to check all your entities especially associations before you use them. Hope it helps you.
If I understand your question correctly, you have your entities already configured and need to auto-generate your proxy and repository classes.
Both can be created using the following Doctrine CLI commands from your application's root directory:
php scripts/doctrine.php orm:generate-proxies
php scripts/doctrine.php orm:generate-repositories library/
If you're looking for a way to auto-generate your entity classes, unfortunately I don't think a solution is available for this yet.
A support rep at ORM Designer said they are "working on" this feature and that it is "very demanded." Here's hoping it will be included in ORM Designer 2.0 since there is generally a lot of repetitive work involved in coding/mapping entity classes that could likely be automated.
You can use the orm:generate-entities command if you provide mapping information in either XML or YAML format.
See http://www.doctrine-project.org/docs/orm/2.1/en/reference/tools.html#entity-generation
For development, set proxy generation to be automatic in your config, otherwise, use the orm:generate-proxies command.
Unless you need to customise your repositories, generic ones are created in the entity manager when requested. To specify custom repositories, simply use the repository-class entity mapping attribute.
See http://www.doctrine-project.org/docs/orm/2.1/en/reference/xml-mapping.html#defining-an-entity for an example