Category: Doctrine ORM

Posted on

Doctrine migrations and Postgis

Using Postgres with the Postgis extension to integrate GeoData / GIS functionality in your project is not natively supported by Doctrine and Doctrine migrations.

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.

Continue reading “Doctrine migrations and Postgis”
Posted on

[Symfony 2] composer.json for a assumed-stable symfony 2 distribution

This small composer.json file is used in a project i am working on atm, feel free to use it at own risk. I will provide non-periodical updates and hopefully soon a full upgrade to symfony 2.1.x including doctrine orm 2.2.x.

I still did not get the point regarding dependency resolution, so i simply “composed” the composer file by writing down my own requirements (“i want only the hottest, newest stuff!!”, then tracked down the error messages, removing them by explicetly writing down the missing dependencies by using the latest “dev-*” versions. After that i tried to run the project, which actually did not work, but selective downgrade of some of the bundles (framework, security-extra blahblah) finally did the job. Continue reading “[Symfony 2] composer.json for a assumed-stable symfony 2 distribution”

Posted on

Silex and MongoDB simply

Using MongoDB in your Silex Project is quite easy.

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.

Continue reading “Silex and MongoDB simply”

Posted on

Symfony 2 wird super. Oder …?

Natürlich wird Symfony 2 super. Die Dokumentation ist wie gewohnt zum jetzigen, frühen Zeitpunkt genial, die Architektur durchdacht, die Entwickler-Community steckt sowieso alles in die Tasche, man sieht einfach: Da steckt eine Menge Arbeit, Hirnschmalz und Erfahrung hinter. Aber genug geschleimt ;)

Mein Lieblingsthema ist ja zur Zeit der Dependency Injection Container. Und irgendwie stinkt mir die ganze Container-Konfiguration noch gewaltig. Meine kläglichen Versuche, selbst mal so was ähnliches wie eine brauchbare Autowiring-Implementierung herunterzubrechen, waren natürlich auch bzw. erst recht nicht der große Wurf – was vor allem daran lag, dass ich den Service Container und damit den ganzen Sinn und Zweck des Ganzen einfach mal wegrationalisiert hatte – Loose Coupling sieht natürlich anders aus, das sei den Kritikern zugestanden. Ich verteidige mich mal dadurch, dass ich eigentlich nur mal mit Mixins rumspielen wollte – da hab’ ich wohl die eine oder andere Begrifflichkeit durcheinander geworfen.

Aber um mal zu des Pudels Kern zu kommen: Ist es wirklich so geil, mit kilometerlangen XML-Dateien, ‘ner Menge Initialisierungscode und ohne mit der heißgeliebten Code-Completion in der IDE meiner Wahl ein Paradigma zu kaufen, das im speziellen Anwendungskontext – nicht im Framework-Kontext – eher selten Anwendung findet?

Continue reading “Symfony 2 wird super. Oder …?”

Posted on

Symfony 2 PR3: doctrine:schema:create liefert “No Metadata Classes to process.”

Die Doku stellt in Aussicht, dass man den “normalen” Doctrine-Namespace-Shortcut benutzen kann, also bspw. @Entity anstelle von @DoctrineOrmMappingEntity. Funktioniert aber nicht, weil in irgend einer Service-Configuration dieser Namespace auf einen Alias gemapped wird, der da lautet “orm”. Die Syntax lautet aber nun auch nicht @ormEntity, sondern @orm:Entity. Schreibt man sein Model also bspw. so:

<?php

namespace ApplicationHelloBundleEntity;

/**
 * ApplicationHelloBundleEntityUser
 *
 * @orm:Table(name="users")
 * @orm:Entity
 */
class User
{
  /**
   * @var integer $id
   *
   * @orm:Column(name="id", type="integer")
   * @orm:Id
   * @orm:GeneratedValue(strategy="AUTO")
   */
  protected $id;

sollten alle CLI-Tasks auch wunderbar funktionieren. Es bleibt zu hoffen, dass die DI-Services eine reichhaltige Parameter-Dokumentation spendiert kriegen und das ganze Bundle-System eine transparente, dokumentierte API erhalten (wo zum Teufel liegt in der Sandbox bitte der versprochene Doctrine-Controller?)

Die Einstellung findet sich übrigens in der Service-Configuration unter src/vendor/symfony/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml:

<service id="doctrine.orm.metadata_driver.annotation.reader" class="%doctrine.orm.metadata.annotation_reader_class%">
            <call method="setAnnotationNamespaceAlias">
              <argument>DoctrineORMMapping</argument>
              <argument>orm</argument>
            </call>
        </service>

Ist leicht zu finden, wenn man weiß, wonach man suchen muss. Ich denke, es ist am einfachsten, die Service-Definition des DI-Containers an entsprechender Stelle an seine eigenen Bedürfnisse anzupassen. Wie das zuverlässig und projektübergreifend funktioniert, erkläre ich vielleicht mal, wenn ich’s selbst gerafft hab.

Achso, hier noch der Nebensatz (etwas herunter scrollen), in dem gesagt wird, das Jonathan irgendwann mal das “orm:” Präfix einführt. Symfony 2 ist definitiv noch nicht ready for production (was aber auch niemand behauptet).

Posted on

Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen

Unter Dependency Injection versteht man heute nicht nur ein einfaches Entwurfsmuster, sondern vor allem Framework-gestützte Mechanismen, die den konkreten Implementierungsaufwand verringern (Entwicklungszeitoptimierung), dem Entwickler bessere Übersicht über Abhängigkeiten zu schaffen (Applicationdesignoptimierung) und die Anzahl der Instanzen gleichen Prototyps zu minimieren (Performanceoptimierung).

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.
Continue reading “Dependency Injection mit PHP 5.3, Runkit-Erweiterung und Doctrine 2-Annotationen”