First off, thanks for the module it works very well. I was wondering if it was possible to allow an inclusion/exclusion list for database tables when creating a new snapshot. For example, when creating a snapshot could a user specify certain tables to be or not to be rolled back when a database roll back was initiated. For our purposes, we maintain a demo site for an ubercart shopping cart so users can test the store administration backend. It resets every hour. It would be nice if the user table wasn't rolled back every time so people didn't have to re-register for an account to use the backend. This feature could have numerous uses (e.g. keeping a persistent watchdog log that kept track of errors that might be wiped away with a rollback).
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | demo-204033.patch | 9.94 KB | sivaji_ganesh_jojodae |
Comments
Comment #1
sivaji_ganesh_jojodae commentedI do like to see this feature in demo module. Also there is an another duplicate issue #460644: DB Tables: Access Log & Views Object Cache which addresses the same feature. I have rolled a patch against demo 6.x-1.x-dev, please test it and let me know your suggestions.
Once you apply this patch you will be able to see one more form element under "dump settings" which will list all the tables. Demo module will ignore the selected tables. Table contents remain unchanged during the reset and snapshot creation, this is what all this patch does.
Note : This thread/patch is not to fool or make fun of other :P
Comment #2
sunSorry, to avoid you having to put changes like the following into your patch, I have committed a coding-style clean-up to all branches now.
Please re-roll.
Note: I also discussed this quite lengthy with smk-ka:
- There should be two locations to disable tables for dumping and restoring: First one on the primary settings page ("Status") to define the defaults, and a separate one on the snapshot creation form.
- The default selection applies to all snapshots by default. The second can be used to override the defaults to create, say, a full snapshot of the entire site for backup purposes or whatever.
- In either case, only the structure, but no data is dumped for all disabled tables, just like it is done for the hard-coded tables currently.
- We want to store the tables that are contained in a dump in its corresponding .info file. We should display the skipped tables along with the enabled modules on the snapshot overview page and reset form.
- Most likely in a separate issue/patch, we will additionally store a list of all tables in the database at the time of the snapshot creation. That list will be used to identify (new) orphan tables needing to be deleted upon restoring a dump, for example, if you installed a new module after creating a snapshot and revert your site to the snapshot.
Comment #3
sivaji_ganesh_jojodae commentedWow!! the features you have listed above seems to be awesome. I will try to re-roll a patch this weekend.
Sorry for late reply, i was offline because of my exams.
Comment #4
sunWhen implementing this, we have to bear in mind to increase the version number for dumps in .info files. Dumps created with an older version need to be handled more or less like they are now.
And, I'm not sure whether I put that clearly, so just to make that sure: We want to select the disabled, excluded tables (unlike other tools like phpMyAdmin, where you select the tables to export).
Comment #5
sunNote that this has been prepared at the API level to some extent already, due to #535754: Allow other modules to alter dump parameters
Comment #6
gaurav.kapoor commentedNot working on D6 anymore.