2016-05-23 19 views
4

Ich versuche, eine Model/Mapper-Art der Interaktion mit Doctrine DBAL zu implementieren, aber lief ein paar Fragen. Einige meiner Spaltennamen haben am Ende ein '#'. Das Ändern des Namens ist keine Option. Die $ {'COL1 #'} Syntax funktioniert gut für reguläre Variablen, aber PHP scheint es schwer zu haben, wenn es als Objekteigenschaft verwendet wird.Doctrine DBAL -> execute() und Hydration mit DB2-Feldnamen einschließlich '#'

Parse-Fehler: Syntaxfehler, unerwartete '$', variable (T_VARIABLE in ...

erwarten Wie kann ich ein Modell für eine Tabelle mit einem Hashtag im Feldnamen haben

+0

Frage 1: Haben Sie Doctrine-Einheiten konfiguriert? Frage 2: Haben Sie versucht, den Hydrator 'Zend \ Stdlib \ Hydrator \ ClassMethods' zu verwenden, um eine Entity zu hydratisieren? – ceadreak

+0

@ceadreak Ich begann mit Doctrine-Entitäten aufgrund dieses Problems, aber diese Datenbanktabellen sind fast 40 Jahre alt und Relationen sind fast nicht existent. Außerdem haben wir Entwickler, die nicht in PHP arbeiten (andere Sprachen, aber gleiche Tabellen) und ich kann nicht erwarten, dass sie daran denken, eine Entität zu ändern, wenn sie eine Änderung an der Datenbank vornehmen. Ich glaube also, Entitäten sind keine Möglichkeit. Was 'ClassMethods' betrifft, habe ich das zum Hydratisieren benutzt, aber ich musste immer noch jede Reihe durchlaufen. –

+0

Können Sie keine Ansichten in MySQL erstellen und Ihre Spalten in etwas freundlicher umbenennen (ohne '#') ...? Doctrine unterstützt die Verwendung von Ansichten für Ihr Modell. – Wilt

Antwort

3

Sie könnten create views in MySQL und Ihre Spalten etwas umbenennen freundlicher in diesen Ansichten (Somethi ng ohne) ...? So müssen Sie Ihre ursprünglichen Tabellen nicht ändern, aber Sie können diese Benennungsprobleme immer noch umgehen.

Doctrine unterstützt auch the use of views für Ihr Modell.

Sie beziehen sich auf ein anderes Szenario, aber die gleiche Lösung mit Ansichten könnte helfen.

Wie ich verstanden Sie nur Lehre DBAL verwenden, aber trotzdem here some more information auf den Einsatz von MySQL Ansichten mit Lehre ORM, könnte es hilfreich sein (für Sie oder andere).

+0

Danke, das ist nicht die Lösung, mit der ich am Ende war, aber es ist immer noch eine mögliche Lösung für das Problem. Deshalb habe ich dies als Antwort markiert. –

0

I don? Wenn Ihre Datenbank wirklich alt ist (40 Jahre alt, omg!), sollten Sie eine abstrakte DB/Layer-Struktur wie Zend DB verwenden (tut mir leid.) mit ZF2) oder Aura (http://auraphp.com/framework/1.x/en/sql/).

Aber wenn Sie wirklich Doctrine verwenden möchten, sollten Sie Entitäten manuell erstellen und magische Setter - Getter verwenden, um spezielle Felder zu behandeln und auf Ihre Entitäten zuzugreifen/zu hydratisieren.

EDIT

Stellen Sie sich Ihre DB mit einem Tisch Clients und 2 Felder: id und name#1

class Client 
{ 
    protected $id; 
    protected $name1; 

    public function __set() 
    { 
     // here you can set unknown properties 
     // remove '#' e.g ... 
    } 

    public function setName1($name1) 
    { 
     $this->name1 = $name1; 

     return $this; 
    } 

    public function getName1() 
    { 
     return $this->name1; 
    } 

    // ... other accessors 

} 

Verbrauch:

$results = clients_query_result ... 
$hydrator = new ClassMethods(); 
$clients = []; 

foreach ($results as $result) 
{ 
    $client = new Client(); 
    $clients[] = $hydrator->hydrate($result, $client); 
} 

// that's it, now you have a collection of Client objects 
+0

Danke, ich benutze Doctrine DBAL, aber nicht Doctrine ORM. Ich vermutete, dass ich 'Zend \ DB' stattdessen mit' Zend \ Db \ ResultSet \ HydratingResultSet' verwenden könnte, aber das würde immer noch zweimal durch die Ergebnismenge laufen, was ich sagen kann. Ich frage nicht wirklich nach meiner besonderen Situation.Ich bin nur neugierig, ob alle ihre Abfrageergebnisse zweimal durchlaufen, wenn sie Hydratoren verwenden oder wenn es eine andere Methode/einen Trick gibt, von dem ich nichts weiß. Es scheint einfach albern zu sein, zweimal durchzulaufen, aber vielleicht ist die allgemeine Vorstellung, dass ein Modell den zusätzlichen Overhead wert ist. –

+0

Es hängt von Ihren Ergebnissen ab ... Wenn es sich um ein Objekt oder ein Array handelt, können Sie problemlos den ClassMethods-Hydrator verwenden. Aber Sie müssen Doctrine für diesen Fall nicht verwenden. Es ist unmöglich, ein Schema aus Entitäten zu erstellen und keine großen Entitäten aus dem Schema zu erstellen ... Ich habe meine Antwort aktualisiert, um Ihnen ein Beispiel für die Hydrierung von Entitäten und ClassMethods zu zeigen. hoffe, es hilft – ceadreak

+0

ClassMethods kann nicht mit dem Hashtag umgehen. Ich muss 'Zend \ Stdlib \ Hydrator \ ArraySerializable' verwenden und meine Methoden' exchangeArray' und 'getArrayCopy()' so konfigurieren, dass sie die Zuordnung von meinen Tabellennamen zu meinen Objekteigenschaften zuordnen. –