This is surprisingly not intuitive, as you cannot simply pass an array of integers to a prepared statement. Instead, you need to add special binding types to inform Doctrine that this is indeed an array of integers.

It’s very well explained in the documentation under the Parameters Conversion section:
https://www.doctrine-project.org/projects/doctrine-dbal/en/current/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion
But it is rather hard to find and it took me a while.

The trick is to add the array binding types to the the types parameters to the query method. In the case of integers, it is \Doctrine\DBAL\ArrayParameterType::INTEGER.
Now Doctrine knows how to handle the types in the array while binding the values.

Example:

$sql = 'SELECT * FROM items WHERE id IN (?)'; 
$numbersAsStrings = "1,2,3";
$numbers = array_map('intval', explode(',', $numbersAsStrings));
$users = $con->fetchAllAssociative(
  $sql, 
  [$numbers], 
  [ArrayParameterType::INTEGER]
);

If you omit the types, Doctrine will simply try to bind the array as string, which will fail and you get this error:
Array to string conversion

If you try to pass it as a comma-separated string yourself and omit the types like $numbers = implode(',',array_map('intval', explode(',', $numbersAsStrings))); You will get an error because Doctrine expects an array of values for the IN clause and not a string.
Error:
count(): Argument #1 ($value) must be of type Countable|array, string given

I hope this helps someone finding out how to make WHERE IN SQL queries with Doctrine more quickly than me next time.

First you have to add the extension to Postgres, even if you use the Postgis docker image like postgis/postgis:14-3.3-alpine.

So add this SQL statement to the up method of your first migration:
$this->addSql('CREATE EXTENSION IF NOT EXISTS postgis;');

and the DROP statement for the extension to the down method:
$this->addSql('DROP EXTENSION postgis;');

Now, when using Doctrine with Postgres and Postgis extension, migrations still behave a bit odd and try to remove Sequences created by Postgis, because Doctrine migrations does not take Postgis extension’ s built-in Sequences into account.

So you will find this statements in your first migration, which is basically wrong because –of course– we want to keep the topology and tiger Sequences.

	public function up(Schema $schema): void
	{
		// this up() migration is auto-generated, please modify it to your needs
		$this->addSql('DROP SEQUENCE topology.topology_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.county_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.state_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.place_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.cousub_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.edges_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.addrfeat_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.faces_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.featnames_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.addr_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.zcta5_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.tract_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.tabblock_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.bg_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_gaz_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_lex_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_rules_id_seq CASCADE');
	}

	public function down(Schema $schema): void
	{
		// this down() migration is auto-generated, please modify it to your needs
		$this->addSql('CREATE SCHEMA topology');
		$this->addSql('CREATE SCHEMA tiger');
		$this->addSql('CREATE SCHEMA tiger_data');
		$this->addSql('CREATE SEQUENCE topology.topology_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.county_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.state_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.place_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.cousub_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.edges_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.addrfeat_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.faces_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.featnames_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.addr_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.zcta5_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.tract_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.tabblock_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.bg_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_gaz_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_lex_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_rules_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
	}

So we have to teach Doctrine to respect these Postgis features.
Therefor extend the PostgreSqlPlatform class, add the Postgis features as exclude condition to the query:

src/DBAL/PostgisPostgreSqlPlatform.php:

<?php

namespace App\DBAL;

use Doctrine\DBAL\Platforms\PostgreSQLPlatform as PostgreSqlPlatformBase;

class PostgisPostgreSqlPlatform extends PostgreSqlPlatformBase
{
	public function getListNamespacesSQL()
	{
		# exclude postgis schemas
		return "SELECT schema_name AS nspname
				FROM   information_schema.schemata
				WHERE  schema_name NOT LIKE 'pg\_%'
				AND schema_name NOT LIKE 'topology'
				AND schema_name NOT LIKE 'tiger%'
				AND    schema_name != 'information_schema'";
	}

	public function getListSequencesSQL($database)
	{
		return 'SELECT sequence_name AS relname,
					   sequence_schema AS schemaname,
					   minimum_value AS min_value, 
					   increment AS increment_by
				FROM   information_schema.sequences
				WHERE  sequence_catalog = ' . $this->quoteStringLiteral($database) . "
				AND    sequence_schema NOT LIKE 'pg\_%' 
				AND sequence_schema NOT LIKE 'topology%'
				AND sequence_schema NOT LIKE 'tiger%'
				AND    sequence_schema != 'information_schema'";
	}
}

As Gist: https://gist.github.com/ivoba/74a143d8074110ef47f93a581bb0c3f6

Now tell doctrine to use this PostgreSqlPlatform class instead.
In symfony you can add this to config/packages/doctrine.yaml:

doctrine:
	dbal:
		url: '%env(resolve:DATABASE_URL)%'
		types:
			geometry: LongitudeOne\Spatial\DBAL\Types\GeometryType
			point: LongitudeOne\Spatial\DBAL\Types\Geometry\PointType
			polygon: LongitudeOne\Spatial\DBAL\Types\Geometry\PolygonType
			linestring: LongitudeOne\Spatial\DBAL\Types\Geometry\LineStringType
		platform_service: App\DBAL\PostgisPostgreSqlPlatform

This is inspired by this Gist, which does the same for other Postgres extensions: https://gist.github.com/dextervip/a2f384050748d6ee3ed7d573425e9d58

Now you can run your migrations diff bin/console do:mi:di and the Postgis sequences will be respected by the Doctrine.

An exception occurred while executing 'INSERT INTO user (id, email, roles, password, is_verified) VALUES (?, ?, ?, ?, ?)' with params [3, "dev@dev.de", "[]", "your-encrypted-password", 0]:
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "user"
LINE 1: INSERT INTO user (id, email, roles, password, is_verified) V...

To fix this you have to escape the table name on your entity, fe. User.php:

@ORM\Table(name="`user`")

(note the backticks inside the quotes!)

If you generate the entity with maker bundle: bin/console make:entity directly on Postgres the backticks are added automatically.
But not when you switch the DB type. Then you have to add them manually. :)

I will show this with my Superleansilexplate and will integrate it there as an example.
Since i dont want to integrate MongoDB in Superleansilexplate it will just become an additional gist.

Given you have some smaller amount of data like a counter that needs to be stored or other loose coupled datasets, we simply speak to MongoDB “directly” and store the data via Doctrine MongoDB Abstraction Layer.
Since i presume the Data / Document Structure isnt that complex we dont use Doctrine MongoDB ODM (the Object Document Mapper).
If you want to use it instead, try this Silex Extensions.

So we use this SilexExtensions collection and install it via git:

 cd mysilexproject
 git clone git@github.com:fate/Silex-Extensions.git vendor/silex-extension

Then we install the doctrine mongodb libary manually:

 git clone --recursive https://github.com/doctrine/mongodb vendor/mongodb

The extension collection has some more poviders but you can just ignore them and just focus on the MongoDbExtension.

– i actually dont like extensions collections. i would prefer to clone each extensions individually. thou its not much code overhead, but when it comes to the vendor dependencies it can become quite messy IMHO –

Alright now the code.
Edit src/app.php and register the namespace for the extension:

 $app['autoloader']->registerNamespace('SilexExtension', __DIR__ . '/../vendor/silex-extension/src');

Then register the MongoDbExtension;

 $app->register(new SilexExtension\MongoDbExtension(), array(
 'mongodb.class_path' => __DIR__ . '/../vendor/mongodb/lib',
 'mongodb.connection' => array(
 'server' => 'mongodb://mysecretuser:mysecretpassw@localhost',
 'options' => array(),
 'eventmanager' => function($eventmanager) {
 }
 )
 ));

and finally query your MongoDB collection of choice and display the resultset as json:

$app->get('/data-from-mongodb', function() use($app) {

$coll = $app['mongodb']->selectDatabase('mydb')->selectCollection('mycoll');
 $query = array(
 'query' => 'value'
 );
 $sort = array(
 'count' => -1,
 );
 $r = $coll->find($query)->sort($sort)->toArray();
 $response = new Response();
 $response->headers->set('Content-type', 'application/json');
 $response->setContent(json_encode($r));
 return $response;
 });

Easy

So gehts nicht:

Doctrine::getTable('propose')
->createQuery('propose')
->select('propose.cat')
->distinct()
->fetchArray();

Denn das wird dazu:

SELECT DISTINCT p.id AS p__id, p.cat AS p__cat FROM propose p

so gehts:

Doctrine::getTable('propose')
->createQuery('propose')
->select('propose.cat as cat')
->distinct()
->fetchArray();

Denn das wird dazu:

SELECT DISTINCT p.cat AS p__0 FROM propose p

Als zukünftige Ausgaben denkbar sind ein Symfony2-basierendes CMF (Content Management Framework) oder eine auf die speziellen Befürfnisse von Online-Shops zugeschnittene Bundle-Sammlung.

Der Code ist noch nicht als stabil deklariert. Die bereits vorhandene und wie immer intensiv gepflegte Referenz-Dokumentation lädt bereits jetzt zum Reinschnuppern und Ausprobieren ein.

Hier gibt es ein paar Notizen von Jonathan Wage’s Präsentation dazu!

Sehr cool klingt unter anderem auch die writeBehind Geschichte und dass Objekte nicht mehr von Doctrine Klassen abgeleitet werden müssen, sondern mit dem “Entity Managers” zB. gespeichert werden.
Also keine ->save() methoden mehr. :)

“Everything is an entity.” A lightweight persistent domain object, a regular PHP class. You don’t extend a base doctrine class. No final methods.

namespace Entities;
class User
{
private $id;
private $name;
private $address;
}

Note use of namespaces.

EntityManager is central access point to ORM. Used to query for persistent objects. Employs transactional write behind strategy that delays execution of SQL to execute it in the most efficient way.

Erst in den nächsten Monaten wird sich wohl herausstellen, ob der neue Maintainer da auch langfristig Böcke drauf hat. Ich glaube, ich bleibe nach dem ganzen Lernaufwand jetzt erstmal bei Doctrine, da tut sich ja auch noch einiges (Obwohl ich stiller Fan der Criteria-API bin, und Doctrine mit Klammern im WHERE (kommi… komma… kommutativ? irgendwie schon) ist ja immer noch so eine Sache… Doctrine 1.2 zieht mit dem Symfony 1.3 Releasetermin gleich, und da gibt es auch wiederum ein paar tolle neue Features. Übrigens ein Changelog mit sehr viel Stil ;)

Doctrine_Access setzt unter anderem die Schnittstelle ArrayAccess voraus, die seit PHP 5 mit SPL existiert. Jedes Objekt, das diese Schnittstelle erbt, kann wie ein Array behandelt werden:

$obj = new MyArray();

$obj['property'] = "Value";

echo $obj['property'];

Was genau beim Zugriff auf das Objekt oder das Setzen seiner Eigenschaften via Array-Syntax + Zuweisungsoperator geschieht, bleibt dabei dem Entwickler überlassen, der das Verhalten durch die Implementierung der Methoden offsetSet(), offsetUnset(), offsetExists() und offsetGet() steuern kann.

Durch die php-internen magischen Methoden plus ArrayAccess ist es möglich, auf Attribute von Doctrine_Record Instanzen so zuzugreifen:

echo $employee['firstname'];

oder so:

echo $employee->firstname;

oder auch so:

echo $employee->getFirstname();

Letztere Möglichkeit existiert nur im Symfony-Kontext, sprich wenn Doctrine als Symfony-Plugin läuft. Dann nämlich wird dem Model-Generator noch eine Symfony-Klasse “dazwischengeschoben”, nämlich sfDoctrineRecord. Diese Klasse kümmert sich um das Mapping von setXY() und getYZ()-Methoden auf die jeweiligen Accessoren und Mutatoren, die Doctrine bereitsstellt.

Möchte man nun eine dieser Methoden implementieren, also die “Magie” umgehen und seine “eigene” Methode namens setFirstname() implementieren, hat man ein Problem. Da die Sichtbarkeit nicht auf Getter beschränkt ist, könnte man auf die Idee kommen, statt $employee->setFirstname(“Kalle”) einfach $employee->firstname = “Kalle” zu schreiben. Um zu erreichen, dass jeder Mutator-Aufruf, egal welcher Syntax, auf die eigene, konkrete Methode setXYZ() umgeleitet wird, muss man nur eine Doctrine-Umgebungsvariable setzen:

$manager = Doctrine_Manager::getInstance();
$manager->setAttribute('auto_accessor_override', true);

Nun ist aber bei der Implementierung ein wenig Vorsicht geboten:

function setFirstname($firstname){
if(empty($firstname))
{
$this->firstname = "Noname";
}
}

Damit hängen wir in einer Endlos-Schleife fest. Die Lösung ist, sofort den “Endpunkt” aller Mutator-Aufrufe anzuspringen, die Methode _set($attr, $value) (nicht zu verwechseln mit der magischen Methode __(set).

function setFirstname($firstname){
if(empty($firstname))
{
$this->_set('firstname', 'Noname');
}
}

So lässt sich jede Änderung am Objekt protokollieren und bei Bedarf triggern.

Einige sogenannte Core-Behaviours liefert Doctrine ab Werk bereits mit. Zu nennen sind da bspw. die komplexe Tree-Implementierung zur Verwaltung von Baumstrukturen der zugrundeliegenden (relationalen) Datenbank oder die etwas einfacherer Versionierung von Tupeln bis hin zum wirklich simplen, automatisch eingefügten Zeitstempel.

An der Bandbreite der zur Verfügung stehenden Core Behaviours kann man bereits sehen, dass man damit unterschiedlichste Dinge realisieren kann: Bspw. ist “Timestampable” ein reiner Event-Listener, der die Events onSave bzw. onUpdate überwacht und jeweils automatisch die aktuelle Systemzeit mit dem entsprechenden Datensatz speichert.

Die Tree-Implementierung, als Beispiel sei NestedSets genannt, bietet dafür und im Gegensatz zum Timestampable-Verhaltensmuster einen Adapter, der  es dem Programmierer erlaubt, über Iteratoren und gewohnte Entwurfsmuster zum Zugriff auf hierarchische Datenstrukturen die zugrundeliegenden RecordSets zu bearbeiten.

Ein neues Verhaltensmuster erstellen

Anhand eines Beispiels möchte ich kurz zeigen, wie man ziemlich flott und ohne große Kenntnis der Doctrine-Architektur ein eigenes Verhalten zusammendengeln kann. Ich will dabei einerseits ein paar Automatismen via Event-Listener implementieren, andererseits aber auch zwei Helfermethoden schreiben, die mir häufig wiederkehrende Tasks abnehmen.

Die Anforderung ist, Pfade zu vom Benutzer hochgeladenen Dateien in einer Relation abzulegen und auf Integrität zu prüfen. Vorhanden ist bereits eine Abstraktionsschicht für den Zugriff auf das Dateisystem, nennen wir die zuständige Klasse einmal File:

$file = new File('/pfad/zur/datei.jpg');

Um die Funktionalität dieser Klassen mit unserem Doctrine Entities zu nutzen, entwerfen wir ein neues Verhaltensmuster als Ableitung der Klasse Doctrine_Template:

class Doctrine_Template_File  extends Doctrine_Template
{
public function setFile(File $file)
{
}

public function getFile(File $file)
{
}
}

Jedes Template erhält einen Satz an Standardoptionen, die später in der Klassendefinition des Models selbst bzw. im Yaml-Schema überschrieben werden können:

class Doctrine_Template_File  extends Doctrine_Template
{

protected $_options = array(
'name'=>'pathname',
'alias'=>null,
'options'=>array('notnull'=>true),
'checkExistence' => true
);

public function setTableDefinition()
{
$name = $this->_options['name'];
if($this->_options['alias'])
{
$name . = ' as ' . $this->_options['alias'];
$this->hasColumn($name, 'string', 255, $this->_options['options']);
}
}

// ...

Wir haben die Standardoptionen definiert und die Methode SetTableDefinition implementiert, welche unsere Optionen in eine Tabellendefinition aggregiert, also letztlich dafür sorgt, dass hinten ein DDL-Statement herauskommt.

Nun kann man unser brandneues Verhaltensmuster schonmal in eine unserer Tabellen einbauen (Denkt euch die korrekten Indentations einfach dazu, der Codeformatter fluppt nicht so richtig):

FileTuple:
actAs:
File:
name: filename
checkExistence: true

Um das ganze mit etwas Funktionalität anzureichern, implementieren wir anschließend unsere beiden Methoden getFile() und setFile():

public function setFile(File $file)
{
return new File($this->_invoker[$this->getOption('name')]);
}

public function getFile(File $file)
{
$this->_invoker[$this->getOption('name')] = $file->getPathname();
}

Das ist schon die ganze Magie. Über $this->_invoker können wir auf die Instanz von Doctrine_Record zugreifen und dort all die lustigen Spielereien veranstalten, die uns Doctrine gönnt. Rufen wir nun auf einem unserer ObjectModel-Instanzen von FileTuple eine der neuen Methoden auf, so werden diese via __call() auf das Verhaltensmuster gemappt. Somit können wir mit

Doctrine::getTable('FileTuple')->find(1)->getFile();

unsere File-Instanz zum einfachen Zugriff auf das Dateisystem erzeugen. Andersherum ist es möglich, mittels

$file = new FileTuple();
$file->setFile(new File('/pfad/zur/datei.png'));
$file->save();

ein neues RecordSet in unserer Datenbank zu erzeugen.

Als nächstes möchte ich, dass jede Instanz von Doctrine_Record, die mit unserem neuen Verhaltensmuster erzogen wurde, vor dem speichern prüft, ob der zu speichernde Dateipfad auch wirklich in unserem Dateisystem vorhanden ist. Diese Anforderung lösen wir, indem wir einen Eventlistener erzeugen und an unser Verhaltensmuster binden:

public function setTableDefinition()
{
// ...
// ...

$this->addListener(new Doctrine_Template_Listener_File($this->_options));

}

Die Klasse Doctrine_Template_Listener_File erweitert Doctrine_Record_Listener, die wiederum das Interface Doctrine_Record_Listener_Interface implementiert. Dadurch, dass wir Doctrine_Record_Listener erweitern, müssen wir nicht selbst das komplette Interface herunterwurschteln, sondern brauchen nur die Callback-Methoden zu implementieren, die wir benötigen. In diesem Falle interessiert uns der Sprungpunkt “postValidate”:

class Doctrine_Template_Listener_File extends Doctrine_Record_Listener
{
protected $_options;

public function __construct(array $options)
{
$this->_options = $options;
}

public function postValidate(Doctrine_Event $event)
{
if($this->_options['checkExistence'])
{
$file = $event->_invoker->getFile();
if(!$file->fileExists())
{
$error_stack = $event->getInvoker()->getErrorStack();
$error_stack->add($this->_options['name'], 'The file does not exist.');
}
}
}
}

Wieder holen wir mit $event->_invoker die jeweilige Instanz von Doctrine_Record, besorgen und über unser Behaviour via getFile() unser File-Objekt und können nun testen, ob die Datei tatsächlich im Dateisystem existiert:

$file = new FileTuple();
$file->setFile('/pfad/der/nicht/existiert');

// Exception, Validation error!
$file->save();

Das war nur ein kitzekleiner Einblick in das, was mit Behaviours innerhalb der Doctrine-Welt grundsätzlich machbar ist. Einen weiterführenden Artikel gibt es im Doctrine-Kochbuch unter http://doctrine-project.org/blog/cookbook-recipe-relation-dql-behavior. Ansonsten hilft einem zusätzlich ein längerer Blick auf den Code der Core-Behaviours. In Punkto Code-Style sollte man beachten, dass die Doctrine-Welt den Pear/Zend-Coding Guidelines folgt, so enthält jede Klasse grundsätzlich ihren kompletten Namensraum, und die Datei ist jeweils in einem Unterverzeichnis angesiedelt, das ähnlich wie in der Java-Welt den jeweiligen Namespace bildet. In Hinblick auf Abwärtskompatibilität zu php5.3 sollte man das auch so beibehalten. Auf die Ablage der Behaviour-Klassen im Dateisystem und das Autoloading (um das man sich nur kümmern muss, wenn man sich mit Doctrine außerhalb von Symfony bewegt) gehe ich hier nicht gesondert ein.

Zuletzt ist zu sagen, dass das obige Beispiel durchaus einen konkreten Anwendungsfall beschreibt: Ich habe ein ähnliches Verhaltensmuster mit einem meiner Symfony-Plugins gebundlet, dem sfFilebasePlugin. Hier kann Frau – so sie denn möchte – auch einmal reinschauen.