-
Notifications
You must be signed in to change notification settings - Fork 7
Database Backup xml creator #12
Comments
structure infos => the same as in the database.xml? I think it's easy ... an alternative would be json which might even be easier to create (-: |
Yes i think thats the same, if the user didnt edit the database manually ;) so the result has to be a csphere standart database xml file |
If the user edits something in the database all the RAD tools will be dying ... So this is nothing the user should do and just the data should be enough ... |
but if you want to give the plugin backup another user he needs structure AND data. When i make a backup of the plugin, you are able to install the backup as a plugin, this is the restore... So we need full backup including structure in database file... |
"you are able to install the backup as a plugin, this is the restore..." what? I could get a backup. Okay. But what should i do with the backup without the plugin? :-) This data is specific to a specific plugin. But if you want it duplicate, just have fun ... I think more important would be an link to the specific plugin with the name, developer and version number... |
we should discuss that on our next team meeting |
yes @etb09 i think you don`t really realize what i want. There are no difference between plugin and backup of plugin at this moment. That is why it is called backup |
Let's talk about it next monday. As I understud this issue you wanna create a backup of the all the database infos of a specific module. These informations contain the structure and also the data of the plugin . This could be one or more database tables and all the entries which are stored in the tables. Just for one plugin so we could create a database backup of the plugin (which is the title of your issue). Is this what was your intention? What you wanted to say with this issue? If not please describe it so other's could understand what you want ... :-) The following part are my thoughts to this idea and how i would implement things and of which things i would take a specific look. So, in my oppinion these data relates to a specific plugin and is enough described by the database.xml of the plugin in the specific version which should be, together with the plugin name and plugin vendor, also be part of the database backup file. In this case, at a reimport of the data in cSphere, we could identify by parsing the backup file whether the right plugin in the right version is installed to import the data. If there's no matching plugin we could just ignore the new import. For this it might be helpful to have a version-id of the database.xml of the plugin (or something similar, which we should talk about in #13 also), to identify whether it's compatible (maybe plugin version changed but database scheme stays the same so we have more compatibility if the database hasn't changed which in my guess will be 70% of the plugin updates) I will not write any more to this issue. We will discuss monday. So please read it and give me an answer to the question above. If you wanna talk before monday use hangouts or teamspeak ... |
Possibility to create database_backup.xml file for selecet plugin. The file has to have structure infos of the table and the content of the table inside. This is needed for plugin backups.
The text was updated successfully, but these errors were encountered: