atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title><![CDATA[Doctrine]]></title>
    <link href="https://www.doctrine-project.org/atom.xml" rel="self" />
    <link href="https://www.doctrine-project.org/" />
    <updated>2024-12-25T20:19:57-05:00</updated>
    <id>https://www.doctrine-project.org/</id>

            <entry>
            <title type="html"><![CDATA[Doctrine Core Team Meetup, ORM 2.19.8, 2.20.0, 3.3.0 Releases, DBAL 4.2.0]]></title>
            <link href="https://www.doctrine-project.org/2024/10/14/doctrine-core-team-meetup-2024.html"/>
            <updated>2024-10-14T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2024/10/14/doctrine-core-team-meetup-2024.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>Last week, we meet with the Doctrine ORM and MongoDB Core Teams for 3 days in
Bonn, Germany. A few releases followed immediately from that, including some
deprecation reversals and a discussion of our upcoming roadmap.</p>
<ul>
<li><a href="https://github.com/doctrine/orm/releases/tag/3.3.0">Doctrine ORM 3.3.0</a></li>
<li><a href="https://github.com/doctrine/orm/releases/tag/2.20.0">Doctrine ORM 2.20.0</a></li>
<li><a href="https://github.com/doctrine/orm/releases/tag/2.19.8">Doctrine ORM 2.19.8</a></li>
<li><a href="https://github.com/doctrine/dbal/releases/tag/4.2.0">Doctrine DBAL 4.2.0</a></li>
<li><a href="https://github.com/doctrine/migrations/releases/tag/3.8.2">Doctrine Migrations 3.8.2</a></li>
</ul>
<p>We want to thank all our sponsors on
<a href="https://opencollective.com/doctrine">OpenCollective</a> and
<a href="https://github.com/sponsors/doctrine">GitHub</a> for contributing towards making
this in-person team meetup possible. If you are not a sponsor of Doctrine already,
<a href="https://www.doctrine-project.org/sponsorship.html">please consider becoming one</a>.</p>
<h2>Undeprecation of PARTIAL Object Hydration</h2>
<p>Starting with ORM 3.3.0 you can use <code>SELECT PARTIAL</code> DQL syntax again and with
ORM 2.20 you will not get a deprecation message for using that anymore. If your
application uses partial objects with DQL, you can migrate from 2.20 to 3.3.0
now without having to change their use. Partial objects have exactly the same
behavior (and downsides) in version 3 and 2.</p>
<p>Why the change? It was a long time plan to remove partial objects and their
hydration, because of the many edge cases they produced. This plan was in
effect and shipped for 3.0 - 3.2, where the syntax and feature was completely
removed. In discussion with our users we found a lot of use-cases and ideas
that are powerful with partial objects, but were firm on our goal to remove
partial objects.</p>
<p>This all changes with PHP 8.4 and its lazy object feature. With this feature we
will be able to implement partial objects transparently to PHP. That means it
will not be necessary to know if an object is a proxy, a partial object, or a
full object. Whenever a property that is not available is accessed, Doctrine
can load it.</p>
<p>We hope to add this behavior to ORM 3.4 in the next months.</p>
<h2>Support for PHP 8.4 and Property Hooks</h2>
<p>Doctrine supports PHP 8.4 starting with ORM 2.20.0 and 3.3.0, DBAL 4 and 3.</p>
<p>There are caveats though. You cannot use property hooks in entities yet. This
is because we need to rework internally how we read and write property values
(<code>ReflectionProperty::setValue()</code> vs <code>setRawValue()</code> and <code>ReflectionProperty::getValue()</code>
and <code>getRawValue()</code>). For now, if you try to create a property hook on an entity,
Doctrine will throw an exception. We plan to address this with an upcoming ORM
3.4 release, hopefully before PHP 8.4 is released itself, otherwise shortly
after.</p>
<p>For MongoDB ODM, PHP 8.4 support depends on a to-be-completed migration from
ProxyManager to <code>symfony/var-exporter</code>.</p>
<h2>Lazy Objects and PHP 8.4 requirement in ORM 4</h2>
<p>The lazy objects RFC in PHP 8.4 changes everything for the better in Doctrine
ORM internally. This is why we decided that ORM 4 will be mainly a decision
about exclusively using lazy objects and therefore will require PHP 8.4.</p>
<h2>Support for ENUM Database types</h2>
<p>DBAL 4.2 now supports a new Enum type that is mainly useful for introspection
of database schemas that contain enums. All values of the enum are parsed out
of the type and are available to the schema abstraction layer.</p>
<p>Although we do not recommend the enum type in MySQL/MariaDB due to its quirky
implementation details, you can also use this type to directly map columns to
enums in the database via the ORM as of 3.3.0:</p>
<pre><code class="language-php">class Subscription
{
    #[Column(type: "enum", options: ['values' =&gt; ['future', 'active, 'cancelled', 'expired']))]
    public string $state = 'future';
}</code></pre>
<p>You can also map Enums directly to MySQL enums and let Doctrine auto-detect all the configuration:</p>
<pre><code class="language-php">class Subscription
{
    #[Column(type: Types::ENUM)]
    public State $state = State::FUTURE;
}
enum State : string
{
    case FUTURE = 'future';
    case ACTIVE = 'active';
    case CANCELLED = 'cancelled';
    case EXPIRED = 'expired';
}</code></pre>
<p>We have also discussed at length how we can make types parameterized, which
will further improve Doctrine Schema introspection and comparisons with
non-default types.</p>
<h2>Query Cache and Pagination Variables</h2>
<p>If you have used <code>setFirstResult()</code> and <code>setMaxResults()</code> with DQL queries then up
until 2.20.x of Doctrine, each combination of first result and max results lead
to their own DQL query parsing cache entry. This could easily balloon the query
cache size out of control.</p>
<p>Starting with 2.20, the DQL parser is now running in a two-step process, where
the first step generates the cacheable result and the second step amends the
cached result with the LIMIT query part (or other database equivalent).</p>
<p>This is a bigger internal change, and we hope that we thought of all the edge
cases, but it might be possible that especially in combination with the
Paginator abstraction and collection fetch joins, there are some cases
where this change could lead to breaks on upgrading to 2.20 from 2.19.</p>
<h2>DQL: Nested DTOs and Named Arguments</h2>
<p>Starting with ORM 3.3 you can now create nested DTOs with the <code>NEW</code> syntax and
furthermore, use a short named arguments syntax to populate the constructor of
a DTO. This feature was contributed by GitHub user
<a href="https://github.com/eltharin">eltharin</a> over the last few months and builds
upon previous work.</p>
<h2>Migrations: Fixing a decade old schema comparison bug with PostgreSQL</h2>
<p>When you used Doctrine Migrations with the ORM the down migration included a
statement to drop the public schema for the better part of a decade.</p>
<p>This bug has finally been fixed and you won't see this drop schema statement in
newly created migrations for PostgreSQL anymore.</p>
<h2>Psalm and PHPStan going forward</h2>
<p>After a long discussion we have decided to only use one static analysis tool
and Doctrine projects will use PHPStan going forward. For now
Psalm checks will be removed from repositories over the next weeks.</p>
<p>This is mainly because PHPStan has outpaced Psalm in depth and quality in the
last few years and it feels unlikely that Psalm can point to a problem that
PHPStan did not detect before. If in the future Psalm catches up to PHPStan we
may reconsider adding it.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[The skeletons are now out of the closet - So long, Skeleton-Mapper]]></title>
            <link href="https://www.doctrine-project.org/2024/08/16/the-skeletons-are-now-out-of-the-closet.html"/>
            <updated>2024-08-16T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2024/08/16/the-skeletons-are-now-out-of-the-closet.html</id>
            <author><name>Claudio Zizza</name></author>
            <content type="html"><![CDATA[<p>While Doctrine ORM and DBAL have a main focus in our daily development, a deeper look
into their dependencies show, that Doctrine has much more projects at hand than just the
database-related ones. Some projects even weren't created for ORM or DBAL, just like
our Skeleton-Mapper.</p>
<p>The <a href="https://github.com/doctrine/skeleton-mapper">Skeleton-Mapper project</a> won't be maintained anymore because of
its lack of usage nowadays and is now an archived repository. The Doctrine Skeleton-Mapper
was an object mapper where you are responsible for implementing the object mapping of the
persistence operations. This means you write plain old PHP code for the data repositories,
object repositories, object hydrators and object persisters. A lot of freedom but also a lot
of work for a developer, including its maintenance for us.</p>
<p>Some projects grow and others become obsolete after some time, which are 9 years in
the case of our Skeleton-Mapper. We also want to express our gratitude to
<a href="https://github.com/doctrine/skeleton-mapper/graphs/contributors">the contributors</a>
and maintainers who kept this project alive for so long. Thank you.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine Core Team Meetup 2024 in Bonn, Germany]]></title>
            <link href="https://www.doctrine-project.org/2024/07/09/doctrine-core-team-meetup.html"/>
            <updated>2024-07-09T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2024/07/09/doctrine-core-team-meetup.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We are organizing another Doctrine Core Team Meetup in Bonn, Germany from Tuesday,
8.10.2024 to Thursday, 10.10.2024 at the offices of one of our
sponsors Tideways GmbH.</p>
<p>The goal is to get the current team together, discuss and work on Doctrine DBAL, ORM and ODM.</p>
<p>We thank all of our GitHub and OpenCollective sponsors for making this possible.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine ORM 3 and DBAL 4 Released]]></title>
            <link href="https://www.doctrine-project.org/2024/02/03/doctrine-orm-3-and-dbal-4-released.html"/>
            <updated>2024-02-03T00:00:00-05:00</updated>
            <id>https://www.doctrine-project.org/2024/02/03/doctrine-orm-3-and-dbal-4-released.html</id>
            <author><name>Jonathan H. Wage</name></author>
            <content type="html"><![CDATA[<p>We are thrilled to announce the release of Doctrine ORM 3.0 and DBAL 4.0.
These releases are the culmination of over a decade of hard work across
dozens of contributors and the Doctrine maintainers.</p>
<h2>What's New</h2>
<p><strong>A Slimmer, More Efficient ORM</strong>: The new Doctrine ORM 3.0 comes in at
326KB, down from 400KB in ORM 2.18.0. This reduction not only makes the
ORM lighter but also signals our efforts to streamline and optimize every
aspect of our library and focus our maintenance efforts on the core functionality
of an ORM and less on tooling and helpers that are only useful by a small number
of our users.</p>
<p><strong>Enhanced Code Quality and Coverage</strong>: With ORM 3.0, we've pushed our
code coverage from 84% to 89%. For DBAL 4.0, we've pushed our code coverage
from 86% to 94%. This improvement underscores our commitment to reliability
and the stability of the Doctrine ecosystem, ensuring that your applications
run smoothly.</p>
<p><strong>Leaner Dependencies</strong>: In Doctrine ORM 3.0, we have finally eliminated
dependencies on <code>doctrine/cache</code> and <code>doctrine/common</code>. This change reduces
complexity and improves maintainability of Doctrine as we now depend on
<a href="https://www.php-fig.org/psr/psr-6/">PSR-6: Caching Interface</a> for our
caching responsibilities. Implementing a PSR means we are more interoperable
with other frameworks and easier to use by a broader amount of users.</p>
<p><strong>A Growing Community</strong>: The Doctrine project now boasts 1029 contributors
across all its projects. This vibrant community is the backbone of Doctrine,
providing valuable insights, feedback, and contributions that drive the
project forward.</p>
<h2>Upgrading</h2>
<p>We understand that upgrading to a new major version can be difficult. The
best way to upgrade is to first upgrade to the latest Doctrine ORM 2.x and
DBAL 3.x version and address any deprecation warnings that are reported. You
can read more about how Doctrine handles deprecations <a href="https://www.doctrine-project.org/policies/deprecation.html">here</a>.
Once you have addressed all of the deprecations, you should have a clear
path to upgrade.</p>
<p>In addition to that, we've maintained comprehensive documentation about
every change, deprecation and BC break to facilitate a smooth transition
to ORM 3.0 and DBAL 4.0.</p>
<ul>
<li><a href="https://github.com/doctrine/orm/blob/3.0.x/UPGRADE.md">Upgrade to Doctrine ORM 3.0</a></li>
<li><a href="https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md">Upgrade to Doctrine DBAL 4.0</a></li>
</ul>
<h2>The Future of Doctrine ORM 2</h2>
<p>We plan to maintain Doctrine ORM 2 for at least the next 2 years by providing
bug and security fixes. We may also add or deprecate things in 2.x to improve
the existing forward-compatbility layer to make the transition to ORM 3 smoother.</p>
<h2>Looking Forward</h2>
<p>ORM 3 and DBAL 4 are a big step forward towards modernizing the API of our
libraries, increasing safety with the use of scalar types in the code base,
better error handling and generally cleaning up the code to make it easier
to maintain. We look forward to continuing work on Doctrine and focusing on
being the most stable and reliable PHP database persistence related libraries
available.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Archiving Unmaintained Packages]]></title>
            <link href="https://www.doctrine-project.org/2024/01/30/archiving-unmaintained-packages.html"/>
            <updated>2024-01-30T00:00:00-05:00</updated>
            <id>https://www.doctrine-project.org/2024/01/30/archiving-unmaintained-packages.html</id>
            <author><name>Andreas Braun</name></author>
            <content type="html"><![CDATA[<p>After long consideration, we have decided to archive a number of repositories that have not seen any activity in a
while. This affects the CouchDB and OrientDB ODMs and their respective libraries, as well as the KeyValueStore project.
The following repositories and composer packages are affected:</p>
<ul>
<li><a href="https://github.com/doctrine/couchdb-client">doctrine/couchdb</a></li>
<li><a href="https://github.com/doctrine/couchdb-odm">doctrine/couchdb-odm</a></li>
<li><a href="https://github.com/doctrine/DoctrineCouchDBBundle">doctrine/couchdb-odm-bundle</a></li>
<li><a href="https://github.com/doctrine/orientdb-odm">doctrine/orientdb-odm</a></li>
<li><a href="https://github.com/doctrine/KeyValueStore">doctrine/key-value-store</a></li>
</ul>
<p>The composer packages will remain available and installable, but we will not be making any bug fixes or security fixes
in the affected libraries. If you or your business depends on one of these libraries, please fork them and maintain them
yourself in the future.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[ORM 3.0 Beta 1, DBAL 4 RC 1 and future plans]]></title>
            <link href="https://www.doctrine-project.org/2023/10/11/orm3-beta1-dbal4-rc1-future-plans.html"/>
            <updated>2023-10-11T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2023/10/11/orm3-beta1-dbal4-rc1-future-plans.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We have released the <a href="https://github.com/doctrine/orm/releases/tag/3.0.0-beta1">first beta of the long awaited Doctrine ORM
3</a> and a <a href="https://github.com/doctrine/dbal/releases/tag/4.0.0-RC1">release
candidate of DBAL 4</a>. </p>
<p>The target audience for these releases are framework integration and extension
library authors. ORM 3 is not yet production ready and the APIs may change.</p>
<p>Our goal is to release ORM 3.0 as soon as possible and to gather feedback from
greenfield project authors first. </p>
<p>This beta release is the result of a lot of work by many contributors,
especially Grégoire, Alexander, Claudio and Matthias on ORM, Sergei and
Alexander on DBAL.  To iron out the final details, we met in Düsseldorf for a
Doctrine Core Team meeting, generously funded by our sponsors through
OpenCollective and GitHub. We also welcomed Matthias as the latest member of
the Doctrine Core Team.</p>
<h3>Continued ORM 2 support and forward compatibility</h3>
<p>We will maintain the latest branch of the 2 line in ORM for at least another 2
years, possibly longer, to give you enough time to upgrade and us more time to
learn from upgrader feedback and improve forward compatibility.</p>
<p>This means that we will be making ORM 2.x work with newer versions of PHP,
fixing security bugs, and introducing layers and features that help with
forward compatibility in the upgrade path to ORM 3. </p>
<p>Current users of ORM 2 should note that there is no urgency right now to update
to ORM 3, as we are still working on replacement APIs and forward
compatibility, and do not intend to ship them all with ORM 3.0, but with later
versions.</p>
<h3>ORM 2 users can already prepare for 3 by addressing deprecations</h3>
<p>But there is already work to be done as an ORM 2 user: to help you find all the
places where things may be deprecated or changing behaviour, we have created
<a href="https://github.com/doctrine/deprecations#usage-from-consumer-perspective">the doctrine/deprecations
library</a>
and integrated it heavily into DBAL, ORM and other components.</p>
<p>It allows the use of deprecated behaviour to be logged at runtime with low
overhead, automatic suppression of the same deprecation occurring multiple
times, and a way to ignore selected deprecations for the time being. Each
deprecation message always links to a GitHub issue with more details.</p>
<p>Many deprecated features have no replacement, such as Mapping Exporters,
Generate Mapping from Database, Named Queries. </p>
<p>For some of the deprecations in ORM, we are still planning replacement APIs,
especially:</p>
<ul>
<li>There is currently no way to limit the number of entities that the flush
operation considers changed. Flush will currently always calculate change
sets on all entities that are not read-only. </li>
<li>As a replacement for removing PARTIAL object hydration, we are looking at
making embeddable objects lazy, perhaps improving nesting of the new DTO
expression in DQL. We are also looking to introduce subselect or batch
loading for collections for more efficient multi-level hydration.</li>
</ul>
<p>These will be released in 2.x as forward compatible APIs so that you can switch
to using them before upgrading to ORM 3.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine ORM Team Meetup in Bonn, Germany]]></title>
            <link href="https://www.doctrine-project.org/2023/08/21/doctrine-orm-team-meetup.html"/>
            <updated>2023-08-21T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2023/08/21/doctrine-orm-team-meetup.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We are organizing a Doctrine ORM Core Team Meetup in Düsseldorf, Germany from Monday,
9.10.2023 to Wednesday, 11.10.2023 at the offices of one of our primary
sponsors Tideways GmbH.</p>
<p>The goal is to get the current team together, discuss and work on the missing
pieces for the long-awaited Doctrine ORM 3.0 release that is planned for later
this year.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[From annotations to attributes]]></title>
            <link href="https://www.doctrine-project.org/2022/11/04/annotations-to-attributes.html"/>
            <updated>2022-11-04T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2022/11/04/annotations-to-attributes.html</id>
            <author><name>Grégoire Paris</name></author>
            <content type="html"><![CDATA[<p>Last month, we migrated the tests of the ORM from annotations to attributes.
Let us look back on what lead to this moment.</p>
<h2>Annotations</h2>
<p>Let's go 22 years back in time. In October 2000, Ulf Wendel introduces phpdoc
comments at the PHP-Kongress. These comments follow a structure that allows
to produce API documentation from them. They are inspired by javadoc.</p>
<p>In 2002, Alex Buckley, a Specification lead for the Java language publishes
<a href="https://www.cs.ubc.ca/~gregor/teaching/cpsc411/metadata-public-draft.html">JSR-175</a>, thus proposing to add user-defined annotations to the
language, allowing to tag language elements with extra information. 2 years
later, it gets approved and Java 1.5, also known as Java 5 is released, <a href="https://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html">with
support for annotations</a>.</p>
<p>4 more years elapse and in 2006, Jano Suchal publishes <a href="https://github.com/jsuchal/addendum">Addendum</a>, a
PHP library that adds support for using &quot;Docblock/JavaDoc&quot; as annotations,
meaning that contrary to what is done in Java, Addendum annotations are
contained inside phpdoc comments, like this:</p>
<pre><code class="language-php">/** @test */
function test_it_throws_on_invalid_argument(): void
{}</code></pre>
<p>That is because they are implemented in userland, without requiring a change in
PHP itself.</p>
<p>Doctrine ORM 2.0 is not released yet at that point, but <a href="https://github.com/doctrine/orm/commit/bcf0110249978c8fc705916d5a4f94216bb98b07">the library is used to
build an annotation driver</a> in Doctrine 2 in early 2009.
At that time, Doctrine was a project in a single repository, with <code>Common</code>,
<code>DBAL</code> and <code>ORM</code> as top-level namespaces.
<a href="https://github.com/doctrine/orm/commit/9075f10bf5da3058f6ef82ff08e4783ff70424a4">Addendum is replaced 6 months later</a>, with a new namespace
under <code>Common</code> called <code>Annotations</code>.</p>
<p>In the summer of 2010, Guilherme Blanco and Pierrick Charron submit
<a href="https://wiki.php.net/rfc/annotations">an RFC to add annotations support to PHP</a>, but it
<a href="https://externals.io/message/49733">gets declined</a>. The RFC already mentions the
need for annotations in PHPUnit, Symfony, Zend Framework, FLOW3 and of course,
Doctrine.</p>
<p>Late 2010, Doctrine 2 is tagged, and the single repository is split into 3
repositories.</p>
<p>Finally, in 2013, the namespace above is isolated in its own repository, and
<code>doctrine/annotations</code> 1.0.0 is tagged.</p>
<p>Today, the package is widely used in the PHP ecosystem and has a little short
of 300 million downloads on Packagist, and is depended on by over 2 thousand
packages, including major frameworks and tools. It is fair to say annotations
have proven valuable to many users.</p>
<h2>Attributes</h2>
<p>The RFC mentioned above is only one among <a href="https://wiki.php.net/rfc">many</a>. As mentioned
before, annotations were implemented as phpdoc comments, which has several
drawbacks:</p>
<ul>
<li>The comments are necessary to run the code, and <a href="https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.save-comments">need to be kept in the
opcode cache</a>.</li>
<li>They are obtained at runtime, by using the reflection API, and because of
that, can only be detected as invalid at runtime.</li>
<li>They are not well supported by IDEs if at all.</li>
<li>They clutter comments, which were originally intended for humans.</li>
<li>They can be confused with phpdoc, which are something else entirely.</li>
</ul>
<p>In March 2020, Benjamin Eberlei resurrects <a href="https://wiki.php.net/rfc/attributes">Dmitry Stogov's attributes
RFC</a> and submits <a href="https://wiki.php.net/rfc/attributes_v2">the seventh RFC on this
topic</a>, introducing attributes to PHP.</p>
<p>A few rounds of RFCs about syntax later, PHP 8.0 is released, with a notable
feature missing: nested attributes. PHP 8.0 attributes use a syntax that is
forward-compatible with them though, and finally, with PHP 8.1, nested
attributes are supported.</p>
<h2>Migrating from one to the other</h2>
<p>Since attributes are much better than annotations, with <code>doctrine/orm</code> 3.0,
annotations will no longer be supported, which means applications using them as
a way to map entities to tables need to migrate towards attributes (or another
driver).
As maintainers of that library, even we needed to migrate: most of the test
suite of <code>doctrine/orm</code> used annotations.</p>
<p>Enter <a href="https://github.com/rectorphp/rector">Rector</a>. Rector is a standalone tool that is invaluable when it
comes to performing such migrations: it is able to understand PHP code and
apply so-called Rectors to it. It is extensible, so it is possible to define
such Rectors in order to address upgrades for anything, including Doctrine.</p>
<p>What's more, it comes with batteries included: when you install
<code>rector/rector</code>, what you get is code from <code>rector/rector-src</code> <em>and</em> its official
extensions, among which you will find <a href="https://github.com/rectorphp/rector-doctrine"><code>rector/rector-doctrine</code></a>.
That's right, there is already an entire extension dedicated to Doctrine.</p>
<p>Rules are grouped together in sets, and the set that interests us here is
<code>Rector\Doctrine\Set\DoctrineSetList::ANNOTATIONS_TO_ATTRIBUTES</code>.</p>
<p>To migrate <code>doctrine/orm</code>'s test suite to annotations, here is how we
proceeded:</p>
<ol>
<li>Install Rector: <code>composer require --dev rector/rector</code>.</li>
<li>
<p>Create a file called <code>rector.php</code> at the root of the library with the
following contents:</p>
<pre><code class="language-php">    &lt;?php

    declare(strict_types=1);

    use Rector\Config\RectorConfig;
    use Rector\Doctrine\Set\DoctrineSetList;

    return function (RectorConfig $rectorConfig): void {
        $rectorConfig-&gt;paths([
            __DIR__ . '/tests',
        ]);
        $rectorConfig-&gt;sets([
            DoctrineSetList::ANNOTATIONS_TO_ATTRIBUTES,
        ]);
    };</code></pre>
</li>
<li>Run <code>vendor/bin/rector</code>, which obeys the above configuration.</li>
<li>Uninstall Rector: <code>composer remove rector/rector &amp;&amp; rm rector.php</code></li>
<li>Run <code>vendor/bin/phpcbf</code> to make the migrated codebase compliant with our
coding standard.</li>
</ol>
<p>Or at least, it was the plan, because some annotations were not perfectly
migrated. All in all, I found only <a href="https://github.com/rectorphp/rector/issues/7528">2</a> <a href="https://github.com/rectorphp/rector-src/pull/2988">bugs</a>, which looks great
given how so many edge cases should appear in our test suite.</p>
<p>I went on and reported those 2 bugs, and this is where the experience went from
great to stellar:
the issue template leads to <a href="https://getrector.org/demo">a playground</a>, much like the one you can
find for other tools such as Psalm or PHPStan.</p>
<p>This one comes with 2 buttons: &quot;Create an issue&quot;, which pre-fills the Github
issue with useful information, and &quot;Create a test&quot;, that lets you create a test
in the right directory (and also, the right repository, which is
<code>rectorphp/rector-src</code>, and not <code>rectorphp/rector</code>).</p>
<p>If you want to add a new test for the bug you reported, you should let
<a href="https://github.com/rectorphp/rector/blob/main/docs/how_to_add_test_for_rector_rule.md">the official tutorial</a> walk you through that, it is very
well written.</p>
<p>Anyway, now that these 2 bugs are fixed and you know how to migrate, plan that
migration, and let us know how it goes! Happy Rectoring!</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[New Release: Doctrine DBAL 3.4.0]]></title>
            <link href="https://www.doctrine-project.org/2022/08/06/dbal-3.4.0.html"/>
            <updated>2022-08-06T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2022/08/06/dbal-3.4.0.html</id>
            <author><name>Sergei Morozov</name></author>
            <content type="html"><![CDATA[<p>Doctrine is proud to announce the release of Doctrine DBAL 3.4.0. Below is a summary of the most noteworthy changes
in the new release:</p>
<h2>Database schema introspection optimization (<a href="https://github.com/doctrine/dbal/pull/5268">#5268</a>)</h2>
<p>Older DBAL versions, in order to introspect database schema, performed a set of queries for each table individually.
This caused noticeable performance issues on some platforms like Oracle which seemingly rebuild their internal views
for each such query.</p>
<p>As of this release, the entire schema is introspected in a fixed number of queries. The more tables the schema contains,
the more noticeable this optimization should be.</p>
<p>It was impossible to make these optimizations while using the schema introspection platform methods
(e.g. <code>getListTableColumnsSQL()</code>). As a result, although these methods are kept in the codebase for backward
compatibility, the DBAL itself no longer uses them. The SQL queries used for schema introspection are no longer
considered part of the public DBAL API.</p>
<h2>Support for foreign key constraints on SQLite (<a href="https://github.com/doctrine/dbal/pull/5427">#5427</a>)</h2>
<p>Although SQLite has supported foreign key constraints since its earliest versions, their support in the DBAL
was quite limited. One of the reasons for that was that managing foreign key constraints in SQLite is quite different
from the rest of the supported platforms.</p>
<p>For example, when a foreign key constraint is declared, platforms like MySQL require that the referenced table
must already exist. To support creating tables with mutually referencing constraints, the DBAL would
create the tables first and create the constraints via <code>ALTER TABLE … ADD FOREIGN KEY …</code>.</p>
<p>This approach doesn't work with SQLite since it doesn't allow adding constraints to an existing table. Fortunately,
it doesn't require the referenced table to exist at the time of creating the foreign key either.</p>
<p>The new DBAL release introduces a new API for building <code>CREATE TABLE</code> and <code>DROP TABLE</code> statements for multiple tables
which could be tailored to the requirements of a given platform. The <code>AbstractPlatform::supportsForeignKeys()</code> method
is now deprecated since the DBAL supports foreign key constraints on all supported platforms.</p>
<h2>Support for TEXT/BLOB default values on MariaDB (<a href="https://github.com/doctrine/dbal/pull/5332">#5332</a>)</h2>
<p>The platform layer in the DBAL is organized in the way that the code implementing the support for MySQL is also
used to support MariaDB. As a result, even though MariaDB may support certain features the DBAL doesn't support them
because they are not supported by MySQL. One of such features is the default values for TEXT and BLOB columns.</p>
<p>As of the new release, the default TEXT and BLOB values are supported on MariaDB but are still unsupported on MySQL,
even though MySQL supports them as of
release <a href="https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-data-types">8.0.13</a>.</p>
<h2>Support for result caching in QueryBuilder (<a href="https://github.com/doctrine/dbal/pull/5539">#5539</a>)</h2>
<p>The recently added <code>enableResultCache()</code> method of the <code>QueryBuilder</code> class allows specifying the query cache profile
to be used for performing the queries built by the builder.</p>
<h2>PHP 7.4 or newer is required (<a href="https://github.com/doctrine/dbal/pull/5459">#5459</a>)</h2>
<p>The DBAL no longer supports PHP 7.3 since its support by the community ended last year. The codebase now
actively uses such features of PHP 7.4 as
<a href="https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters">covariant return types</a>
and <a href="https://wiki.php.net/rfc/typed_properties_v2">typed properties</a>.</p>
<h2>Deprecations</h2>
<p>In light of the DBAL 4 release planned for later this year, the 3.4.0 release introduces over 30 deprecations which,
as usual, focus on cleaning up obsolete features and making the API more robust and clearer from the
static analysis standpoint.</p>
<p>To learn more about upgrading your application, see the
<a href="https://github.com/doctrine/dbal/blob/3.4.0/UPGRADE.md#upgrade-to-34">upgrade notes</a>. You can find the full
list of changes in the release <a href="https://github.com/doctrine/dbal/milestone/107">milestone</a>.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[On Doctrine Sponsoring with the help of OpenCollective]]></title>
            <link href="https://www.doctrine-project.org/2022/03/24/opencollective.html"/>
            <updated>2022-03-24T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2022/03/24/opencollective.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>To simplify our own administrative burden, we have decided to move over the
funds to <a href="https://opencollective.com/doctrine">OpenCollective</a>, primarily
motivated by the success and positive experience of the new PHP Foundation.</p>
<p>We have started raising money for the Doctrine Project in 2019 through Patreon and
Github Sponsors to support the project. It was planned to organize core team
get-togethers/hackathons, but due to the pandemic we haven't been able to do this.
In addition the legal and tax implications of raising money also caused us
some headaches. </p>
<p>The move to OpenCollective will allow us to delegate much of the administrative
work to them for a small percentage of the raised capital. The fee is a much
smaller amount than the taxes that we had to pay on the raised money
previously, so it is a win-win for us.</p>
<p>We want to assure our sponsors that we still plan to make use of the funds
to further the Doctrine project and we are actively looking to increase our funding
for these goals:</p>
<ul>
<li>
<p>Regularly organize hackathons for Doctrine Core team contributors, including
3-4 days of accommodation, food and travel for roughly 10-15 people.</p>
</li>
<li>
<p>Infrastructure, servers and hosting.</p>
</li>
<li>
<p>Marketing material such as stickers, t-shirts and other small things.</p>
</li>
<li>
<p>If the budget increases significantly we might be able to pay someone part-
or full-time to do maintenance work such as responding to and processing
issues, prepare for new PHP releases and general cleanups of the codebase.</p>
</li>
</ul>
<p>As such we hope to convince you to sponsor Doctrine through either our <a href="https://github.com/sponsors/doctrine/">Github
Sponsors</a> or
<a href="https://opencollective.com/doctrine">OpenCollective</a> directly.</p>]]></content>
        </entry>
    </feed>