You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mod_odbc_cdr has a useful feature that when writes to the database fail, the data is written to a CSV file. (It can also write every time to another CSV).
The snag is that only the data is written (the part of the SQL query after "VALUES"). As the number and order of fields varies for each insert, to put the data back into the database, you need to delve into the logs to find the rest of each SQL query.
It would be really useful if instead of just writing just the data to a CSV, the 'on failure' part wrote the whole INSERT query. That way after the failure is fixed, it is trivially replayed into the database.
The code to modify is in mod_odbc_cdr lines 342-370 (in v1.10.11), that code writes both the query and the CSV, so the information is right there.
For backwards compatibility the existing CSV behavior needs to be kept, so the new behaviour of writing SQL could be controlled by a new parameters along the lines of the existing CSV parameters: "write-sql" (with values as the CSV equivalent) and the path "sql-path-on-fail".
The text was updated successfully, but these errors were encountered:
mod_odbc_cdr has a useful feature that when writes to the database fail, the data is written to a CSV file. (It can also write every time to another CSV).
The snag is that only the data is written (the part of the SQL query after "VALUES"). As the number and order of fields varies for each insert, to put the data back into the database, you need to delve into the logs to find the rest of each SQL query.
It would be really useful if instead of just writing just the data to a CSV, the 'on failure' part wrote the whole INSERT query. That way after the failure is fixed, it is trivially replayed into the database.
The code to modify is in mod_odbc_cdr lines 342-370 (in v1.10.11), that code writes both the query and the CSV, so the information is right there.
For backwards compatibility the existing CSV behavior needs to be kept, so the new behaviour of writing SQL could be controlled by a new parameters along the lines of the existing CSV parameters: "write-sql" (with values as the CSV equivalent) and the path "sql-path-on-fail".
The text was updated successfully, but these errors were encountered: