Repository-Metriken
- Stars
- (1.711 Stars)
- PR-Merge-Metriken
- (Keine gemergten PRs in 30 T)
Beschreibung
We often have this kind of use case:
- Read src_accounts.csv file and write to
accountstable on PostgreSQL - Read src_payments.csv file and write to
paymentstable on PostgreSQL - Read src_requests.csv file and write to
requeststable on PostgreSQL
In this case, we need multiple configuration files and multiple embulk run commands.
Idea here is to add a simple multi-transaction feature to embulk.
For example, the configuration file can be like this:
jobs:
accounts:
payments:
requests:
in:
type: file
path_prefix: src_${job}
parser:
type: csv
out:
type: postgresql
table: table_${job}
Discussion points are guess, transaction, next config diff and resume.
As the result of guess, we can output this config file:
jobs:
accounts:
in:
parser:
type: csv
columns:
- {name: id, type: long}
- {name: surename, type: string}
- {name: givenname, type: string}
payments:
in:
parser:
type: csv
columns:
- {name: id, type: long}
- {name: timestamp, type: timestamp, format: format: '%Y-%m-%d %H:%M:%S.%N'}
requests:
in:
parser:
type: csv
columns:
- {name: request_id, type: string}
- {name: account_id, type: long}
- {name: timestamp, type: timestamp, format: format: '%Y-%m-%d %H:%M:%S.%N'}
in:
type: file
path_prefix: src_${job}
parser:
type: csv
out:
type: postgresql
table: table_${job}
About transaction, an idea is to commit jobs one by one when all jobs are completed. For example, embulk runs transactions in this order:
- job
accountsbegins (1 task) - job
paymentsbegins (2 tasks) - job
requestsbegins (2 tasks) - job
accountstask-1 completes - job
paymentstask-1 completes - job
requeststask-1 completes - job
paymentstask-2 completes - job
requeststask-2 completes - job
requestscommits - job
paymentscommits - job
accountscommits
A concern is that requests and payments won't be rolled back when commit of job accounts fails.
DSL (https://github.com/embulk/embulk/issues/131) does similar thing. Any thoughts?