Download the PHP package 3slab/vdm-library-doctrine-transport-bundle without Composer
On this page you can find all versions of the php package 3slab/vdm-library-doctrine-transport-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download 3slab/vdm-library-doctrine-transport-bundle
More information about 3slab/vdm-library-doctrine-transport-bundle
Files in 3slab/vdm-library-doctrine-transport-bundle
Package vdm-library-doctrine-transport-bundle
Short Description Vdm Doctrine Transport
License proprietary
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package vdm-library-doctrine-transport-bundle
Vdm Library Doctrine Transport
Installation
You need to have either (or both) doctrine ORM or ODM installed
Or
Configuration reference
There are two parts ton configure: the transport, and Doctrine's behaviour.
Transport
In messenger.yaml:
| Configuration | Description |
|---|---|
| dsn | Use vdm+doctrine_orm:// (if entity manager) or vdm+doctrine_odm:// (if document manager). Optionnaly, you can specify the connection to use with vdm+doctrine_orm://mycustomconnection (fits into doctrine.orm.xxx_entity_manager). |
| options.doctrine_executor | set the id (in the container of services) of a custom doctrine executor to use instead of the DefaultDoctrineExecutor |
| options.default_entity | set the class of default entity to populate if none passed in the message metadatas |
| options.entities | Array of entities to register. At least one entity must be declared. |
| options.entities.FQCN.selector | (optional) Define how the executor will try and fetch a pre-existing entity before persisting (see below) |
Fetching pre-existing entity
Before persisting anything, this transport will always try to find an existing entity. You need to tell it how to proceed. You have several ways of doing it.
The natural way
It means that your entity bears a unique identifier value, such as:
If this value is carried by the incoming message, then you have nothing to configure. The only responsability on your end is making sure there is a public getter for this property (if there isn't you'll get a clear error message anyway).
Note: in this case, the sender will use the find method on the repository.
Multifield with natural getters
In case you don't have a mono-column primary key (ex: no key at all or composite key), you can turn to another
approach and tell the executor which fields should be used to retrieve a pre-existing entity. For instance, if
your entity has two fields representing its identity (let's say code and hash), and they both have a natural
getter (i.e. getCode and getHash), then you need to configure the options like this:
Under the hood, the repository will be called like:
Note: Notice the findOneBy. The sender will use the first matching entity. It's your responsability to provide
a unique set of filter.
Multifield with non-natural getters
In case the fields related to the identity have unnatural getters (ex: legacy code, multilingual code), you can
define which getter to use to fetch the appropriate property. Let's say the identity is made of two fields: label
and hash, which respective getters are getLibelle() and hash(). You will need configure the sender as such:
Under the hood, the repository will be called like:
The same policy as natural getters apply: you have to make sure it returns something as unique as possible.
You can define several entities at once, and mix natural and non-natural getters. However, you will have to prefix your natural getters with integer keys. The key itself doesn't matter (as long as you don't create duplicates), it just needs to be an integer. If the key is an integer, the getter will be guessed. Otherwise, the getter will be what you provide
Under the hood, the repository will fetch the entities like this:
Doctrine Executor
Doctrine executor allows you to customize the behavior of the doctrine ORM transport per transport definition
inside your messenger.yaml file.
If you don't set a custom doctrine_executor option when declaring the transport, the default
DefaultDoctrineExecutor is used.
You can override this behavior in your project by providing a class that extends
Vdm\Bundle\LibraryDoctrineTransportBundle\Executor\AbstractDoctrineExecutor.
Then references this custom executor in your transport definition in your project messenger.yaml :
Entity/Document Matching
For the transport to know to which entities or documents the payload should be persisted, you can either :
- provide the entity's fully qualified class name in the message's metadata, with key
entity. Examplenew Metadata('entity', 'App\Entity\Foo'). - configure a default entity on the transport level
Limitations
You cannot use different connections for different entities within one single transport. Should you have such a need, you should define one transport per connection, extends the library's Message (one per producer) and route the correct message to the correct producer.
