Download the PHP package innmind/doctrine without Composer
On this page you can find all versions of the php package innmind/doctrine. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download innmind/doctrine
More information about innmind/doctrine
Files in innmind/doctrine
Package doctrine
Short Description Declarative approach to eliminate state where not necessary
License MIT
Homepage http://github.com/innmind/doctrine
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 doctrine
doctrine
[!IMPORTANT] This project has been a stepping stone for the Formal ORM. It's no longer actively maintained and will be archived at some point.
This library is an abstraction on top of Doctrine with the intention to remove all implicit states.
Managing the state in an application can become hard when the codebase grows and states (especially implicit ones) is one of the source of bugs in applications.
Doctrine is usually the default choice (not an actual fact) when interacting with databases as it comes bundled with Symfony. Its interface cover many use cases but expose many implicit states such as transactions or cursors in collections.
This is solved here by using principles from the functional programming paradigm.
Installation
Design choices
Click to expand
### `Sequence` vs `Set` `Set` has been discarded for this library as the unicity of entities cannot be guaranted from the returned collections. It also would prevent the use of the `map` function as many entities may be mapped to a single new value, this may lead to unexpected behaviour for newcomers to such paradigm. This is mainly why the choice has been toward `Sequence`. In case you really want to use sets, you may use [`innmind/immutable`](https://github.com/innmind/immutable/#set). ### Enforcing the use of an `Id` Doctrine allows you to generate an id for you when your entities are persisted. This is an implicit state change. In order to avoid this implicit you need to specify the id before persisting your entities. This prevents you from relying on the auto generated id from your database as you can't avoid collisions. The unique solution (that I'm aware of) is to use `UUID`s. The `Id` provided by this library use them so you don't have to think of it anymore. ### A single `Id` class for all entities This is no longer a problem as it is provided with a template understood by [`vimeo/psalm`](https://github.com/vimeo/psalm/blob/master/docs/annotating_code/templated_annotations.md). ### No `flush` method on the `Manager` Being free to call the `persist` and `flush` methods when you wish it opens the door to implicit states in your codebase. You may end up either flushing unwanted persisted entities (`persist` calls before an error occured) or forgetting to `flush` persisted entities (resulting in lost state change). Here this is avoided by forcing to execute all mutations in a given context (via `Manager::mutate()` and `Manager::transaction()`). So it's always all or nothing.Usage
All the use cases below use the code declared in the example folder.
Pre-requisite for all use cases:
Fetching all entities from the database
Note: The queries are delayed to the last moment possible to leverage the database as most as possible.
Pagination
Filtering
It uses the Specification pattern (normalized in the library innmind/specification).
This example is the equivalent of SELECT * FROM user WHERE username = 'alice' OR username = 'jane' ORDER BY username OFFSET 20 LIMIT 10.
Note: This chain of method calls result once again in a single database call.
Adding new entities
If you try to call Repository::add() or Repository::remove() outside the function it will raise an exception.
Note: If the function throws an exception or an Either::left is returned then nothing will be flushed to the database.
Transactions
Note: Call the $flush function only when in a context of imports as it will detach all the entities from entity manager, meaning if you kept references to entities they will no longer be understood by doctrine
Accessing the values inside a sequence
Sometimes you may want to manipulate an array so it can be used with php functions such as json_encode.
Filtering on relations
You can specify the property of an entity relationship in a specification property field.
The Child specification use the property children.username thus specifying the username of a user's children.
Note: for now only one level relationship is allowed in a specification property.
Lazy loading collections
In certain cases the amount of entities you will fetch won't fit in memory. To still work with this king of scenario you need to use a lazy Sequence and perform periodic clears.
Note: this feature won't work however if you use bi-directional relationships in your entities, for some reason doctrine won't free memory.
Note 2: you should only use this feature when reading data. Using this in a write context may have unexpected side effects!
All versions of doctrine with dependencies
innmind/immutable Version ~4.0|~5.0
doctrine/orm Version ^2.7
ramsey/uuid Version ^4.0
innmind/specification Version ~4.0