Building on #81, I want to support "physical" SQL tables (not SQL views) that are generated by a SQL script or code that VALVE does not control. Here are some initial thoughts:
in the "table" table the "type" should be 'generated'
the "column" table should define the columns for a generated table, as usual
VALVE should create the table (with CREATE TABLE) but it should not create corresponding *_conflict table, or *_view or *_text views
VALVE should be allowed to drop and truncate these generated tables, I think
when asked to load a generated table, there are two cases:
a. if the "path" points to a SQL file, then VALVE will execute that SQL
b. otherwise, VALVE should check that the path exists and has executable permissions; if so, VALVE should execute it, passing the database connection details and the table name as arguments; VALVE should wait for the process to complete; if the process exits with a non-zero status, VALVE should give up and exit
VALVE should not save generated tables ~-- but maybe a manual valve.save(table, path) would be OK?~
VALVE should not edit rows in a generated table
it would be nice if VALVE could still validate rows for generated tables using valve.validate_row()
Building on #81, I want to support "physical" SQL tables (not SQL views) that are generated by a SQL script or code that VALVE does not control. Here are some initial thoughts:
*_conflict
table, or*_view
or*_text
viewsvalve.save(table, path)
would be OK?~valve.validate_row()