Kexi/Migration: Difference between revisions
< Kexi
No edit summary |
|||
Line 3: | Line 3: | ||
*Status: TODO | *Status: TODO | ||
*{{wish|305505}} | *{{wish|305505}} | ||
===Rationale=== | |||
Inserting (or rather appending) CSV data into an existing table gives a simple means for merging CSV data chunks in one step. | |||
===Assumptions & Requirements=== | |||
*The data should be appended to the existing table, without changes made to the | |||
*Data is in largely the same format (regarding column or data types) as the data used to create the original table, to achieve this: | |||
**Data types for columns should be taken from the schema of the destination table | |||
**Column names stay untouched in the destination table, however autodetection should be still used to figure out value of the "First row contains column names" option; the option can be changed in the | |||
*Conflicts resolutions: | |||
**Data type violations (for example when importing string when numeric value is expected): TODO - for 2.6 we need to have friendly error message at least | |||
***Future: propose skipping conflicting values | |||
**Primary key violations: TODO - for 2.6 we need to have friendly error message at least | |||
***Future: propose skipping records with conflicting values or replacing the old records with new ones | |||
**Future: unique key violations: TODO | |||
==Porting to non-modal assistants== | ==Porting to non-modal assistants== |
Revision as of 19:53, 24 September 2012
Add support for inserting CSV data into an existing table
- Status: TODO
- Wish #305505
Rationale
Inserting (or rather appending) CSV data into an existing table gives a simple means for merging CSV data chunks in one step.
Assumptions & Requirements
- The data should be appended to the existing table, without changes made to the
- Data is in largely the same format (regarding column or data types) as the data used to create the original table, to achieve this:
- Data types for columns should be taken from the schema of the destination table
- Column names stay untouched in the destination table, however autodetection should be still used to figure out value of the "First row contains column names" option; the option can be changed in the
- Conflicts resolutions:
- Data type violations (for example when importing string when numeric value is expected): TODO - for 2.6 we need to have friendly error message at least
- Future: propose skipping conflicting values
- Primary key violations: TODO - for 2.6 we need to have friendly error message at least
- Future: propose skipping records with conflicting values or replacing the old records with new ones
- Future: unique key violations: TODO
- Data type violations (for example when importing string when numeric value is expected): TODO - for 2.6 we need to have friendly error message at least
Porting to non-modal assistants
- Status: TODO
What is involved in porting to the new gui? <jstaniek>: We sit and design the given assistant and I am helping with using the API and possibly extending/fixing it. The difference is that many imports can be started concurrently so some extra checking may be needed but this is a side note. Also e.g. user could try to edit/remove a source table during export. So this is fun. But after the change the GUI would be a lot more natural I think.