DbRep: Wie Primärschlüsselverletzung ignorieren?

[MarcusR]

Hi zusammen,

ich versuche gerade einen robusten Datenabgleich (nicht 1:1 sondern schleppende Datenübernahme) abzubilden. In einem anderen Thread hat mit Heiko drauf gebracht, die Zieldatenbank einfach mit einem Primärschlüssel zur Sicherung der Eindeutigkeit der Datensätze zu belegen, sodass ich die abzugleichende Datenmenge nicht mehr trennscharf formulieren muss.

Jetzt stolpert aber DbRep über die Fehlermeldung der Ziel-Datenbank, die sich über die verletztung der Schlüssel beschwert sobald ein Datensatz geschrieben werden soll, den es schon gibt.

Kann man DbRep beibringen, Schlüsselverletzungen bzw. Fehlermeldungen dazu zu ignorieren? Oder weiß jemand, ob man MySQL entsprechend konfigurieren könnte?
Oder kann man vielleicht DbLog überzeugen, einen Inkrementor zu verwenden damit ich mir beim Export die exakte Stelle merken kann?


Viele Grüße
Marcus

[DS_Starter]

Hi Marcus,

hast ja schon angefangen. 

Stolpert DBRep wirklich oder irritieren dich nur die Fehlermeldunge, die natürlich bei einer Schlüsselverletzung auftauchen ?
Es gibt keine Fehlermeldungen bei Schlüsselverletzungen weil mit "Insert Ignore" gearbeitet wird. Habe es gerade nochmal bei mir ausprobiert.

Wenn DbRep dann wirklich nichts speichern sollte muß ich nochmal nachkorrigieren.

Gib mal bitte ein paar Logauszüge.

Grüße
Heiko

[MarcusR]

Hi Heiko,

als DbRep mit Status "Error" zurückgekommen ist, ging ich davon aus, dass keine Änderung gespeichert wurde, so hatte ich zumindest Deine Anleitung verstanden

Es wird aber tatsächlich kein Datensatz ergänzt oder angefasst.

Hier die Fehlermeldung von DbRep:

Code Auswählen Erweitern

DBD::mysql::st execute failed: Duplicate entry '2017-06-04 00:00:33-homematic.kombisensor-CUL_HM-brightness-0' for key 'PRIMARY' at ./FHEM/93_DbRep.pm line 3228, <FH> line 1.

Und hier der Auszug aus dem Log (Quelle: logdb.export; Ziel: archivedb_test.man):

Code Auswählen Erweitern

2017.06.04 14:04:07 3: DbRep logdb.export - Number of exported datasets from /opt/fhem/fhem.db to file current_day.csv: 4747
2017.06.04 14:04:54 3: DbRep archivedb_test.man - Number of imported datasets to fhem_test from file current_day.csv: 4747
2017.06.04 14:06:15 3: DbRep logdb.export - Number of exported datasets from /opt/fhem/fhem.db to file current_day.csv: 4750
2017.06.04 14:06:55 3: DbRep logdb.export - Number of exported datasets from /opt/fhem/fhem.db to file current_day.csv: 4764
2017.06.04 14:07:04 2: DbRep archivedb_test.man - Failed to insert new dataset into database: DBD::mysql::st execute failed: Duplicate entry '2017-06-04 00:00:33-homematic.kombisensor-CUL_HM-brightness-0' for key 'PRIMARY' at ./FHEM/93_DbRep.pm line 3228, <FH> line 1.

Hier noch ein Auszug mit maxVerbose:

Code Auswählen Erweitern

2017.06.04 14:13:04 4: DbRep archivedb_test.man - -------- New selection ---------
2017.06.04 14:13:04 4: DbRep archivedb_test.man - Aggregation: no
2017.06.04 14:13:04 4: DbRep archivedb_test.man - Command: importFromFile
2017.06.04 14:13:04 5: DbRep archivedb_test.man - Timestamp begin epocheseconds: 0
2017.06.04 14:13:04 4: DbRep archivedb_test.man - Timestamp begin human readable: 1970-01-01 01:00:00
2017.06.04 14:13:04 5: DbRep archivedb_test.man - Timestamp end epocheseconds: 1496578384
2017.06.04 14:13:04 4: DbRep archivedb_test.man - Timestamp end human readable: 2017-06-04 14:13:04
2017.06.04 14:13:04 5: DbRep archivedb_test.man - weekday of start for selection: Do  ->  wdadd: 345600
2017.06.04 14:13:04 4: DbRep archivedb_test.man -> Start BlockingCall impfile_Push
2017.06.04 14:13:04 5: DbRep archivedb_test.man -> data to insert Timestamp: 2017-06-04 00:00:33, Device: homematic.kombisensor, Type: CUL_HM, Event: brightness: 0, Reading: brightness, Value: 0, Unit: 
2017.06.04 14:13:04 2: DbRep archivedb_test.man - Failed to insert new dataset into database: DBD::mysql::st execute failed: Duplicate entry '2017-06-04 00:00:33-homematic.kombisensor-CUL_HM-brightness-0' for key 'PRIMARY' at ./FHEM/93_DbRep.pm line 3228, <FH> line 1.

2017.06.04 14:13:04 4: DbRep archivedb_test.man -> BlockingCall impfile_Push finished
2017.06.04 14:13:04 4: DbRep archivedb_test.man -> Start BlockingCall impfile_PushDone
2017.06.04 14:13:04 4: DbRep archivedb_test.man -> BlockingCall impfile_PushDone finished

Ciao,
      Marcus

[DS_Starter]

Hi Marcus,

welche Version von DbRep hast du ?
Muß mindesten 4.12.2 sein.

Ansonsten mach mal ein List vom DbRep bitte.

Grüße
Heiko

[MarcusR]

Hmmm, dumme Frage: Wie ermittle ich die Version?

"version" zeigt mir lediglich:

Code Auswählen Erweitern

93_DbRep.pm            13805 2017-03-26 10:11:50Z DS_Starter

[DS_Starter]

Wie ermittle ich die Version?

Die springt dich als Internal VERSION in der Detailansicht von DbRep an 

[MarcusR]

Hmprf, das war so offensichtlich, dass es mir gar nicht in den Sinn kam

Nach den Update auf besagte (scheinbar recht junge ) Version klappt das alles prima.

Ein DbRep-Instanz exportiert at-gesteuert die letzten 2 Stunden aus der LogDb und eine weitere DbRep-Instanzt importiert (notify-gesteuert) nach erfolgtem Export die Daten in die Archiv-Datenbank

Danke nochmals!

Ciao,
        Marcus

[DS_Starter]

Hi Marcus,

das klingt doch super 
Mit deiner automatisierten Lösung zur Datenübernahme könntest du ja das Wiki ergänzen wenn du magst. Das ist bestimmt für den interessierten Nutzer eine Anregung.

Nach den Update auf besagte (scheinbar recht junge ) Version klappt das alles prima.

Ja, ich entwickle am DbRep mehr oder weniger kontinuierlich weiter. In DbLog haben wir den primary key support auch noch nicht allzu lange implementiert.
Es lohnt sich also ab und an im DbRep-Thread zu schauen ob und was es neues gibt.

schöne Restpfingsten noch...

Heiko