Kexi/Plugins/Tables/Backups: Difference between revisions
| Line 17: | Line 17: | ||
==Details== | ==Details== | ||
'''Advantages.''' Explicit backup can be considered as more systematic approach to plain tables copying: | |||
*backups are listed within context of given table, so unlike the plain copies they do not clutter the object list | |||
*user do not have to 'invent' a name for copied table, and backup description is optional; presentation of backup data is often enough for the user to identify backups | |||
'''Integraion with the Kexi GUI.''' Proposed backup should be available within Tools, as a Backup Data button. There should be also Show Backups button to show existing backups for current object (if it's a table), enabling retrieving table from backup. | '''Integraion with the Kexi GUI.''' Proposed backup should be available within Tools, as a Backup Data button. There should be also Show Backups button to show existing backups for current object (if it's a table), enabling retrieving table from backup. | ||
'''Physical layer.''' Backups shall be indexed by backup date and optional textual description. kexi__objectdata can store this metadata. | '''Physical layer.''' Backups shall be indexed by backup date and optional textual description. kexi__objectdata can store this metadata. Table backups can be created by deep-copying original table to a different name, preferable is kexi__**** so the backup is hidden even in previous Kexi versions. | ||
==Extensions== | ==Extensions== | ||
Backing up any objects and entire database. | Backing up any objects and entire database. | ||
Revision as of 06:50, 5 September 2012
Design page for task: "Add support for table backups".
- Started: Jstaniek September 2012
- Wish #306270
- Target: 2.6.0
Rationale
Support for table backups would be a simple but useful feature for many reasons. Before doing data edit user may decide create backup of relevant table(s). It may be faster and lighter than backing up entire database.
Other uses
Another case can be user editing schema for table that already contains data.
I propose to also backup table automatically before performing schema alteration using the new more powerful Alter Table feature. We'll have to test the feature for some extended time, so backing up by default is good. Moreover tables are not that big considering performance of the current hardware.
Details
Advantages. Explicit backup can be considered as more systematic approach to plain tables copying:
- backups are listed within context of given table, so unlike the plain copies they do not clutter the object list
- user do not have to 'invent' a name for copied table, and backup description is optional; presentation of backup data is often enough for the user to identify backups
Integraion with the Kexi GUI. Proposed backup should be available within Tools, as a Backup Data button. There should be also Show Backups button to show existing backups for current object (if it's a table), enabling retrieving table from backup.
Physical layer. Backups shall be indexed by backup date and optional textual description. kexi__objectdata can store this metadata. Table backups can be created by deep-copying original table to a different name, preferable is kexi__**** so the backup is hidden even in previous Kexi versions.
Extensions
Backing up any objects and entire database.