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>2026-03-09T21:58:12-04:00</updated>
    <id>https://www.doctrine-project.org/</id>

            <entry>
            <title type="html"><![CDATA[New in MongoDB ODM: Queryable Encryption and Vector Search]]></title>
            <link href="https://www.doctrine-project.org/2025/10/20/mongodb-odm-release-vector-encryption.html"/>
            <updated>2025-10-20T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2025/10/20/mongodb-odm-release-vector-encryption.html</id>
            <author><name>Jérôme Tamarelle</name></author>
            <content type="html"><![CDATA[<p>We are pleased to announce the releases of Doctrine MongoDB ODM 2.12.0 and 2.13.0, which introduce two major new capabilities: <a href="https://www.mongodb.com/docs/manual/core/queryable-encryption">Queryable Encryption</a> and <a href="https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview">Vector Search</a>.</p>
<ul>
<li>Version 2.12.0 adds support for Client-Side and Queryable Encryption – <a href="https://github.com/doctrine/mongodb-odm/releases/tag/2.12.0">View the release notes</a></li>
<li>Version 2.13.0 introduces Vector Search and a new Vector field type – <a href="https://github.com/doctrine/mongodb-odm/releases/tag/2.13.0">View the release notes</a></li>
</ul>
<h1>Queryable and Client-Side Encryption</h1>
<p>Version 2.12 integrates support for MongoDB Queryable Encryption and Client-Side Field Level Encryption (CSFLE). These features allow applications to encrypt sensitive fields before sending data to the database, while still supporting equality and range queries on those encrypted fields. The ODM now provides direct integration with these encryption capabilities, allowing encrypted fields to be defined within document mappings. This enables applications to handle confidential data such as personal or financial information securely without sacrificing query functionality. For details and examples, see the <a href="https://www.doctrine-project.org/projects/doctrine-mongodb-bundle/en/5.5/encryption.html">Encryption documentation of the Doctrine MongoDB Bundle</a> or the FreeCodeCamp tutorial to <a href="https://www.youtube.com/watch?v=UuknxVdqzb4">Build Secure Web Applications with PHP, Symfony, and MongoDB</a></p>
<h1>Vector Search</h1>
<p>Version 2.13 adds Vector Search, enabling semantic and similarity queries directly through the ODM. It introduces new vector field types and support for the <code>$vectorSearch</code> aggregation stage. With Vector Search, you can store and query embedding vectors in MongoDB, making it easier to build semantic search, recommendation, and AI-driven retrieval applications without a separate vector database. This feature integrates cleanly with the ODM aggregation builder, making vector-based queries straightforward to implement. Learn more in the <a href="https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.13/cookbook/vector-search.html">Vector Search Cookbook</a>.</p>
<h1>Full-Text Search</h1>
<p>The ODM also supports MongoDB Atlas Search, the built-in full-text search solution that operates directly within MongoDB Atlas. Atlas Search provides powerful full-text, relevance, and vector-based search capabilities using indexes that are automatically updated from your collections. This eliminates the need for a separate search engine or an external indexing pipeline.</p>
<p>Vector and full-text search features rely on MongoDB Atlas, but they can also be tested and run locally or in continuous integration environments using a <a href="https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-local/">Local Atlas Deployment</a>. This makes it possible to develop and test Atlas Search and Vector Search functionality without requiring a cloud deployment.</p>
<p>For more details on how to integrate Atlas Search in your project, see the <a href="https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.13/cookbook/simple-search-engine.html">Simple Search Engine Cookbook</a>.</p>
<p>With the addition of Queryable Encryption and Vector Search, ODM now supports three advanced capabilities in a single stack:</p>
<ul>
<li>Full-text search with Atlas Search</li>
<li>Semantic similarity search with Vector Search</li>
<li>Secure queryable storage with Client-Side Encryption</li>
</ul>
<h1>Upgrading</h1>
<p>New minor releases in the 2.x branch are backward-compatible. Before using new features, make sure your MongoDB server and PHP driver versions support these features. Queryable Encryption requires MongoDB 7.0 or later with client-side encryption configured, and Vector Search requires MongoDB 6.0.11 or later (or MongoDB Atlas with vector search enabled). Full details are available in the <a href="https://github.com/doctrine/mongodb-odm/releases">MongoDB ODM release notes</a>.</p>
<h1>Acknowledgements</h1>
<p>MongoDB Inc. is committed to the Doctrine project and supports it by providing engineers who work alongside community contributors to maintain and evolve the ODM. This collaboration ensures that the library continues to support the latest MongoDB features and remains a reliable and modern tool for PHP developers.</p>
<p>Doctrine MongoDB ODM continues to evolve with the MongoDB ecosystem, bringing together security, full-text search, and semantic capabilities in one consistent data layer.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[An update on the ORM 2 End of Life]]></title>
            <link href="https://www.doctrine-project.org/2025/10/08/an-update-on-the-orm-2-end-of-life.html"/>
            <updated>2025-10-08T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2025/10/08/an-update-on-the-orm-2-end-of-life.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>As part of our Core team meetup in Paris this October 2025, we discussed what the next steps are for ORM 2 and its end of life. </p>
<p>ORM 3 was released almost 2 years ago, and we initially planned with the ORM 2 EOL for February 2026. </p>
<p>So far adoption of ORM 3 is about 25-30% of ORM 2 based on Packagist installation numbers, which is not a big enough number. DBAL adoption of major 3 is much higher at roughly 60%.</p>
<p>Therefore we are going to push out the ORM 2 End of Life to at least February 2027, but we will restrict what kind of changes are eligible for the 2.x branch further.</p>
<p>Starting March 2026, we will only merge changes of the following kind into 2.x branches:</p>
<ul>
<li>PHP version compatibility, let's say support for PHP 8.5, 8.6 or 9.0</li>
<li>Security fixes</li>
<li>Improving forward compatibility with ORM 3</li>
</ul>
<p>But we recommend that you take this next year to plan the upgrade for your applications.</p>
<p>We have made the upgrade smoother, by taking back some deprecations since the initial 3.0 release (namely partial objects), and improved the upgrade path for others. We also improved the <a href="https://github.com/doctrine/dbal/blob/3.10.x/UPGRADE.md">upgrade guides to DBAL 3</a> and <a href="https://github.com/doctrine/orm/blob/3.5.x/UPGRADE.md">upgrade guides to ORM 3</a> with further information.</p>
<p>We also ask you to help us understand and improve forward compatibility by participating in this discussion <a href="https://github.com/doctrine/orm/discussions/12193">What is blocking you from upgrading from ORM 2 to ORM 3? #12193</a></p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine Core Team Meetup 2025 in Paris, France]]></title>
            <link href="https://www.doctrine-project.org/2025/07/01/doctrine-core-team-meetup-paris25.html"/>
            <updated>2025-07-01T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2025/07/01/doctrine-core-team-meetup-paris25.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We are organizing another Doctrine Core Team Meetup in Paris, France from
Tuesday, 7.10.2025 to Thursday, 09.10.2025. We are happy that
<a href="https://jolicode.com/">JoliCode</a> will open their offices for us to meet. </p>
<p>The event is organized and hosted by <a href="https://tideways.com">Tideways GmbH</a> to
allow our international contributors the visit to the European Union.</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 <a href="https://github.com/sponsors/doctrine#sponsors">GitHub</a> and
<a href="https://opencollective.com/doctrine">OpenCollective</a> sponsors for making this
possible.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[ORM 3.4.0 released with Native Lazy Objects and Property hooks support]]></title>
            <link href="https://www.doctrine-project.org/2025/06/28/orm-3.4.0-released.html"/>
            <updated>2025-06-28T00:00:00-04:00</updated>
            <id>https://www.doctrine-project.org/2025/06/28/orm-3.4.0-released.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>Last week we have <a href="https://github.com/doctrine/orm/releases/tag/3.4.0">released Doctrine 3.4.0</a> which primarily adds support for PHP 8.4 functionality:</p>
<ul>
<li><a href="https://www.php.net/manual/en/language.oop5.property-hooks.php">Property Hooks</a></li>
<li><a href="https://www.php.net/manual/en/language.oop5.lazy-objects.php">Native Lazy Objects</a></li>
</ul>
<p>From my perspective, this marks a new era for Doctrine ORM, one that can be
compared with the invention of Reflection based mapping in Doctrine 2.0 way
back in 2010.</p>
<p>For one, this now allows to use public properties for entities by default
without having to fear consequences down the line. Expressed with our Doctrine tutorial
example it looks like this:</p>
<pre><code class="language-php">&lt;?php

#[ORM\Entity]
#[ORM\Table(name: 'bugs')]
class Bug
{
    #[ORM\Id]
    #[ORM\Column]
    #[ORM\GeneratedValue]
    public ?int $id = null;

    #[ORM\Column]
    public string $description;

    #[ORM\Column]
    public DateTime $created;

    #[ORM\Column]
    public string $status;

    #[ORM\ManyToOne(targetEntity: User::class, inversedBy: 'assignedBugs')]
    public ?User $engineer = null {
        get =&gt; $this-&gt;engineer;
        set (?User $value) {
            $value?-&gt;assignedTo($this);
            $this-&gt;engineer = $value;
        }
    }

    #[ORM\ManyToOne(targetEntity: User::class, inversedBy: 'reportedBugs')]
    public ?User $reporter = null {
        get =&gt; $this-&gt;reporter;
        set (?User $value) {
            $value?-&gt;addReportedBug($this);
            $this-&gt;reporter = $value;
        }
    }

    public function __construct()
    {
        $this-&gt;created = new DateTime('now');
    }
}</code></pre>
<p>This reduces the boilerplate code for entities massively by getting rid of
getters and setters.</p>
<p>Furthermore, with native lazy objects we do not have to resort to hacks anymore
for public properties to work and this avoids the performance hit that was
previously there.</p>
<p>Native lazy objects make lazy objects a breeze to implement on our end, it
avoids code generation entirely and the overhead of using them is as minimal as
it gets at runtime.</p>
<p>During the major version 3 cycle, you need to opt into native lazy objects via
configuration:</p>
<pre><code class="language-php">&lt;?php
use Doctrine\ORM\ORMSetup;

$config = ORMSetup::createAttributeMetadataConfiguration(
    paths: [__DIR__ . '/src'],
    isDevMode: true,
);
$config-&gt;enableNativeLazyObjects(true);</code></pre>
<h2>Upgrade Path from 2.x for Lazy Proxies</h2>
<p>Many of you are still on Doctrine ORM 2.x (~75% based on packagist installation
numbers), so the question is how to upgrade.</p>
<p>With native lazy objects we have added a change that allows you to skip the
migration to use lazy ghosts from Symfony VarExporter component.</p>
<p>Previously we thought migrating from our homegrown proxy library to Symfony
would be the next step, but now we think you should directly move towards
native lazy objects.</p>
<p>If you prepare to migrate to 3.4+ and run PHP 8.4 then we recommend that you
skip using <code>symfony/var-exporter</code> for lazy object generation and ignore the
deprecation:</p>
<pre><code class="language-php">&lt;?php
$config-&gt;setLazyGhostObjectEnabled(false);
Deprecation::ignoreDeprecations('https://github.com/doctrine/orm/pull/10837/');</code></pre>
<p>Then when you have prepared for all other deprecations and changes, you
upgrade to 3.4.x and enable native lazy objects in one step.</p>
<p>This simplifies the migration by not having to migrate to different lazy object
strategies multiple times.</p>
<h2>General Upgrade Path from 2.x</h2>
<p>With the re-adding of PARTIAL queries, the move towards native lazy objects
the only two deprecations that we haven't fully addressed yet for a migration
towards 3.x is</p>
<ul>
<li>the use of an argument for <code>EntityManager::flush($entity)</code>
(<a href="https://github.com/doctrine/orm/issues/8459">#8459</a>).</li>
<li><code>Query::toIterable</code> is not a full replacement for <code>Query::iterate</code>
(<a href="https://github.com/doctrine/orm/issues/9219">#9219</a>)</li>
</ul>
<h2>Towards 4.0</h2>
<p>This release is a first step towards ORM 4.0, which will require PHP 8.4 and
is going to be built on native lazy objects functionality completely.
Work on 4.0 has started now and we are hopeful to release it soon.</p>
<p>We have started planning our next hackathon in autumn, most likely a good chunk
of work can be planned and completed then and a release could be right after or
early next year.</p>]]></content>
        </entry>
            <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/HEAD/UPGRADE.md">Upgrade to Doctrine ORM 3.0</a></li>
<li><a href="https://github.com/doctrine/dbal/blob/HEAD/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>
    </feed>