2013-03-22 10 views
5

Ich versuche, meine eigene Zeitstempelmethode zu schreiben, die während der Migration ausgeführt wird. Die eine, die vorhanden ist, fügt jetzt eine NOT_NULL-Einschränkung für das Feld hinzu, und das möchte ich wirklich nicht.Rails/Ruby Wie überschreibe ich die Zeitstempel der Migrationsmethode

Das Problem, das ich habe, ist, dass ich eine Datenbank mit mehreren Schemas habe. Wo jeder Hauptkunde sein eigenes Schema bekommt. Wenn wir einen neuen Client an Bord haben, erstellen wir einen neuen Mandanteneintrag und führen dann eine Migration für ein neu erstelltes Schema durch.

Das neue Schema soll eine exakte Kopie der Tabellen in den anderen Schemas sein, außer natürlich ohne Daten.

Die letzte Migration, die ich ausgeführt habe, war eine etwas ältere Version von Schienen. Immer noch in den 3ern, aber eine Kleinigkeit älter. Als die Zeitstempel erstellt wurden, waren sie NULLable. Als ich die Migration neulich (auf einem neuen Schienen) lief ... Nun sind alle Felder jetzt NOT_NULL

Ich habe Code, der mit der Idee entwickelt wurde, dass updated_at nur gefüllt wurde, wenn der Datensatz aktualisiert wurde ... nicht wenn es erstellt wurde. (Apps und Datenbank "Funktionen" von Drittanbietern erstellen die Datensätze) .. Die Drittanbieter-Apps und Datenbankfunktionen, die Datensätze erstellen, sind auf dem neuen Schema ... Ich habe alle NOT_NULL Einschränkungen für alle entfernt und entfernt die Tabellen manuell, aber ich möchte die Bereinigung nicht direkt in meine Migrationsaufgabe schreiben müssen, so dass alle zukünftigen Tabellen korrigiert werden.

Ich dachte, das Beste, was zu tun ist, war die Zeitstempel-Methode zu überschreiben geändert, zurück zu einem, der den bestehenden Code nicht kaputt gemacht hat.

Also gibt es den Grund, ich muss zurücksetzen/überschreiben.
Meine Frage ist jetzt ... Wie überschreibe ich die Methode. Ich kann nicht eine klare Klassenpfad, um es sehen, und ich bin mir nicht ganz sicher, wie es außer Kraft zu setzen ..

Antwort

4

Setzen Sie dies in einen Affen Patch ... Einfach wie!

class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::TableDefinition 
    def timestamps(*args) 
    options = args.extract_options! 
    column(:created_at, :datetime, options) 
    column(:updated_at, :datetime, options) 
    end 
end 

Wie Maniek sagte. Aktualisierungen von Schienen werden wegen dieser "Reparatur" ignoriert.

Aber sein anfängliches Angebot tut das gleiche. Um seine Fehlerbehebung zu ermöglichen, müssen Sie ältere Migrationen erneut durchführen und "Zeitstempel" durch den neuen Code ersetzen. Fügen Sie dazu hinzu, dass Sie auch alle zukünftigen automatisch generierten Migrationen ersetzen müssen.

Ich denke nicht, dass das passt gut mit DRY .. Es passt auch nicht in SPOT.

Nur B carefulllll!

1

was ist los mit:

create_table :foo do |t| 
    t.text :bar 
    t.datetime :created_at 
    t.datetime :updated_at 
end 

?

+0

Ich habe bereits über 50 Migrationen an Ort und Stelle, ich möchte nicht durch sie hindurchgehen, sie alle zu diesem Paradigma zu verändern. Ich möchte auch nicht den Code in Rails Create Scaffold ändern müssen, so dass es die defekte Datetime anstelle von Timestamps einfügt. – baash05

+3

@daveatflow das Ändern der Migrationen würde sicherlich weniger als die Eingabe der Frage erfordern :) Wo soll man übergehen: Sicherlich kann man Rake-Aufgaben mit aktiviertem Debuggen ausführen. Setzen Sie einen Debugger-Aufruf in einen create_table-Block, gehen Sie in die timestamps-Methode. Sie sollten den Speicherort der Datei ermitteln. Ich persönlich empfehle es nicht, da sich dies auch in zukünftigen Schienenversionen ändern könnte. – maniek

+0

Nun, wie ich schon sagte, ich habe über 50 Migrationen, ich müsste sie alle ändern, und alle zukünftigen Migration von Schienen generiert.Ich müsste auch dokumentieren, dass andere Migrationsschienen neu angelegt werden mussten. Die Debuggerlogik ... jetzt ist das schlau. Um die Änderung in zukünftigen Versionen. Ich versuche genau das zu vermeiden. Wenn sie die Feldnamen ändern (zum Beispiel), dann habe ich eine Datenbank, zwei Schemas, die identisch sein sollten, aber unterschiedliche Feldnamen haben. – baash05

Verwandte Themen