Tomas Vortuba has a new post to his site sharing a few reasons why he thinks that Doctrine isn't dead and is still "alive and kicking" with things still changing in the project.

Almost 1,5 year ago I wrote Why is Doctrine Dying. I didn't use dead, because it's is just state of time being. Open-source projects - like people - tend to find themselves on the top, being stuck or struggling with the right path from time to time. It's a completely normal process of evolution.

I don't know if that post helped it, but since then many things changed for better in Doctrine project. Saying that this post deprecates my old view and celebrate changes.

May this be an inspiration for open-source projects that find themselves stuck and the maintainers that find themselves unhappy.

His list includes reasons like:

• Bump PHP 7.1 Without Waiting for Major Release
• Cut the Weight to Save Yourself
• From Talks and Post Evangelization to Code Improvements
• New Release as a Baseline

For each point, he provides a little clarification and background from commits to the code and statistics about the community around the project.

Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

The Pehapkari.cz blog has continued their series covering domain-driven design with the latest post in the series showing some alternative relational database mapping techniques.

Do you think that multilingual text must always be in a separate database table? Than this article is for you!

We will show that not all arrays have to be mapped as database tables. And we will also show the Doctrine implementation.

The article starts with a bit of background on what they're trying to accomplish: adding internationalization functionality to an e-commerce application. In order to make it simpler to work with the multi-language requirements they show the abstraction of its handling out into a LangValue value object that's used to store the product name value for each language. They then use this and some JSON encoded data to store the different language strings in the database directly with the product record rather than a different table. It then shows how to create the matching Doctrine entity for the LangValueType to work with the serialized column data and extract data from it's JSON blob.

On his Medium site Dragos Holban has a new tutorial posted as a part of his "Learn Symfony 2.8" series. This time he shows how to use Symfony OAuth authentication for a mobile application.

Let’s say you built an API using Symfony and you need to access it from a mobile application using authenticated requests on behalf of your users.

Here’s how to make this work using Symfony 2.8 and Doctrine.

He starts by helping you install the FOSOAuthServerBundle and how to enable it in your Symfony application's configuration. He then includes the code for the OAuth classes: the client and entities for the access token and access token handler. He shows how to configure the bundle and add in routing and configure security protection for the parts of your application. Next he shows the creation of a client and how to document your API using the NelmioApiDocBundle.

Ruslan Karimov has written up a post for the 4xxi.com blog covering the use of custom types with Symfony and Doctrine to implement features specific to your database of choice.

ORMs are great. In theory, they insure you against potential changes in your RDBMS and offer an easy plug’n’play solution for integration your domain code with database. In practice, however, since ORMs have to be compatible with all major vendors, their possibilities are often limited. Perks and tricks of specific RDBMS are left out.

One of such perks is so-called range types in PostgreSQL. There are plenty of cases when range types are applicable, but people (in my experience) often stick to old solution with two separate DATETIME columns. Last time I asked a fellow developer about the reason behind it and they said: ‘I use Doctrine in my project, and Doctrine does not support it’. So here we are.

He starts with a brief introduction to a custom type in Doctrine and a ranged type in PostgreSQL. He then shows how to create a custom "DateReangeType" to work with the ranged types and how add it to your Symfony configuration as a custom type. He ends the post with an example of it in use in an entity and in the client code making the database request. Full code can be found in this Github repository.

On the Madisoft Labs site they've posted a tutorial looking at how to split out your application's data into shards, showing how to do it using Doctrine in a Symfony application.

In the previous article we explored why sharding by tenant is a very good solution for us. In this article we dig into how to divide our Symfony app by shard. [...] We chose Doctrine as our ORM so let’s see what it offers to us.

First of all you have to note that Doctrine is composed mainly by two different parts: DBAL and ORM. ORM leverages DBAL functionalities and it’s completely transparent for sharding. DBAL is the layer we’re interested in.

The author then walks you through the configuration required to make the sharding work including default and a global connections. Next they show the creation of a ShardChoser class that reads a configuration option provided and pulls in the configuration that matches (from YAML files). Finally the ShardManager class is created to handle the connection pool that also includes a "query all" method allowing for the execution of the same SQL on all shards.

In a recent post to his site Tomas Votruba shares some of his opinions about why he thinks that Doctrine is dying sharing three of the reasons he sees for this trend.

Do you use Doctrine ORM? If so, do you follow its evolution on Github? Symfony is evolving, Laravel is evolving, Nette is evolving, world is evolving... Doctrine not. Today I will show you 3 reasons why.

I've been thinking over 2 years about this post. I wasn't sure if it's only negative hype feeling or real thing. It's still the same so it's time to write about it.

He starts off by stating that Doctrine is "an awesome tool" but suggests that it is stuck in its legacy world and hasn't been able to evolve much past some of its original functionality. In his opinion this is because of the project's "system setup" not the code quality or maintainers. He then offers the Doctrine project three suggestions on what they could do to help change the course of the project. This includes becoming more competition to other options and consolidating the 20+ Doctrine repositories down to a much simpler structure.

Robert Basic has written up a quick post to his site sharing details on how you can use Doctrine's DBAL with Zend Expressive without having to use the entire Doctrine ORM. DBAL is Doctrine's abstraction layer that makes it easier to work with your database at a higher level than writing manual SQL statements.

The database abstraction and access layer — Doctrine DBAL — which I prefer over other abstraction layers like Zend DB. My good friend James, aka Asgrim, has written already how to integrate Zend Expressive and Doctrine ORM.

But what if want to use only the DBAL with Zend Expressive, and not the entire ORM? It’s pretty easy as all we need to do is write one short factory that will create the database connection using the connection parameters we provide to it.

He includes the code snippet you'll need to define a "ConnectionFactory" to set up the connection and the configuration needed to allow it to connect to the database. He then shows how to set up the DI container with the new container factory as a dependency and use it by pulling the "db" object out of the container.

Amine Matmati has written up a post with a few quick points refuting the "bloated framwork" myth as it relates to the Symfony framework.

At work, we’re trying to choose which PHP framework to use for our next project. As we’re breaking up our monolithic app into services, only micro frameworks were considered by the team. This choice was made to avoid the pain points we’ve encountered using our current full stack framework.

Not all full stack frameworks are created equal, however. Having worked with Symfony before, I proposed it as an option. As expected, I’ve had some pushback from my fellow coworkers. The main reason being that Symfony is bloated and overkill for our needs.

He then goes on to talk about how, despite many Symfony components being used individually by other projects, the overall framework still has the reputation for bloat. He goes through some of the main points usually mentioned by the opponents:

• Doctrine is complex/bad/slow
• Symfony is too verbose
• Symfony uses too much configuration

He does agree with some of the points made but usually not in the general way they've been stated. For example, while he does agree that Symfony is verbose he also points out that this verbosity provides more control to the developer as to exactly how things hook together.

Rob Allen has posted a tutorial to his site making some updates to his previous work with the Doctrine migrations handling as a standalone component. In this new tutorial he talks about the newer way to use it in your projects.

Since, I last wrote about using the Doctrine project's Migrations tool independently of Doctrine's ORM, it's now stable and much easier to get going with.

He starts with the basic installation and configuration of the migrations tool, making use of a SQLite database as an example. He then shows the use of the basics of using it to make database changes:

• creating a new migration
• running the migrations

Each step comes with code, the commands you'll need to execute and an example of the resulting console output.