Doctrine 2 command line tool

A safe approach would be generating the SQL on development server and saving it into SQL Migration files that are executed manually on the production server.

SchemaTool assumes your Doctrine Project uses the given database on its own. Update and Drop commands will mess with other tables if they are not related to the current project that is using Doctrine. Please be careful! To generate your database schema from your Doctrine mapping files you can use the SchemaTool class or the schema-tool Console Command.

When using the SchemaTool class directly, create your schema using the createSchema method. First create an instance of the SchemaTool and pass it an instance of the EntityManager that you want to use to create the schema.

This method receives an array of ClassMetadataInfo instances. To drop the schema you can use the dropSchema method. This drops all the tables that are currently used by your metadata model. When you are changing your metadata a lot during development you might want to drop the complete database instead of only the tables of the current model to clean up with orphaned tables. You can also use database introspection to update your schema easily with the updateSchema method.

It will compare your existing database schema to the passed array of ClassMetdataInfo instances. If you want to use this functionality from the command line you can use the schema-tool command. To create the schema use the create command:. To drop the schema use the drop command:. As you would think, if you want to update your schema use the update command:.

All of the above commands also accept a --dump-sql option that will output the SQL for the ran operation. When using the Annotation Mapping Driver you have to either setup your autoloader in the cli-config.

This command is not suited for constant usage. It is a little helper and does not support all the mapping edge cases very well. You still have to put work in your entities after using this command. You just have to include the composer autoload file in your project:.

Once you have prepared the class loading, you acquire an EntityManager instance. Inside the Setup methods several assumptions are made:. If you want to configure Doctrine in more detail, take a look at the Advanced Configuration section. The third block shows the configuration options required to connect to a database, in my case a file-based sqlite database. All the configuration options for all the shipped drivers are given in the DBAL Configuration section of the manual. The last block shows how the EntityManager is obtained from a factory method.

Now that we have defined the Metadata mappings and bootstrapped the EntityManager we want to generate the relational database schema from it. Doctrine has a Command-Line Interface that allows you to access the SchemaTool, a component that generates the required tables to work with the metadata.

For the command-line tool to work a cli-config. Its a fairly simple file:. We start with the simplest entity, the Product. The id field has no setter since, generally speaking, your code should not set this value since it represents a database id value. Note that Doctrine itself can still set the value using the Reflection API instead of a defined setter function. The next step for persistence with Doctrine is to describe the structure of the Product entity to Doctrine using a metadata language.

The metadata language describes how entities, their properties and references should be persisted and what constraints should be applied to them. References in the text will be made to the XML mapping. The top-level entity definition tag specifies information about the class and table-name.

The primitive type Product name is defined as a field attribute. Specifying both flags --force and -dump-sql prints and executes the DDL statements.

What is happening here? Using the Product is pretty standard OOP. The interesting bits are the use of the EntityManager service. To notify the EntityManager that a new entity should be inserted into the database you have to call persist. To initiate a transaction to actually perform the insertion, You have to explicitly call flush on the EntityManager. Using this approach the write-performance is significantly better than in a scenario where updates are done for each entity in isolation.

Doctrine follows the UnitOfWork pattern which additionally detects all entities that were fetched and have changed during the request. As a next step we want to fetch a list of all the Products. The EntityManager getRepository method can create a finder object called a repository for every entity.

It is provided by Doctrine and contains some finder methods such as findAll. Updating a product name demonstrates the functionality UnitOfWork of pattern discussed before.

We only need to find a product entity and all changes to its properties are written to the database:. All of the properties discussed so far are simple string and integer values, for example the id fields of the entities, their names, description, status and change dates.

Next we will model the dynamic relationships between the entities by defining the references between entities. References between objects are foreign keys in the database. You never have to and never should work with the foreign keys directly, only with the objects that represent the foreign key through their own identity. On the inverse sides of these foreign keys you can have OneToMany associations. Obviously you can have ManyToMany associations that connect two tables with each other through a join table with two foreign keys.

Now that you know the basics about references in Doctrine, we can extend the domain model to match the requirements:. Whenever an entity is recreated from the database, an Collection implementation of the type Doctrine is injected into your entity instead of an array. Compared to the ArrayCollection this implementation helps the Doctrine ORM understand the changes that have happened to the collection which are noteworthy for persistence.

Additionally you should be aware that dumping the EntityManager to a Browser may take several minutes, and the Debug::dump method just ignores any occurrences of it in Proxy instances. You can learn more about the database connection configuration in the Doctrine DBAL connection configuration reference. Doctrine ships with a number of command line tools that are very helpful during development.

You can call this command from the Composer binary directory:. You need to register your applications EntityManager to the console tool to make use of the tasks by creating a cli-config. Translate Loading What are Entities? Entity Classes How can I add default values to a column?