CiviCRM Community Forums (archive)

any specific reason why using mysqldump which basically does exactly that does not meet your needs?

lobo

hmm, not sure i understand. for backup purposes, you should use mysqldump or a relevant backup utility for mysql

what would the functionality of "export all" be that mysqldump would not cover?

lobo

and how is your use case below connected with this thread? i think i'm missing something

lobo

I have some thoughts on the benefits of a simple "export all" function as opposed to a MySQL dump.

First, I think what I really want is a "backup and restore" function, rather than just "export all." Ideally this function would come in two flavors. One would backup your contact records, including their event registrations, constributions, memberships, relationships, etc. -- all of the stuff that's associated with a particular user. This way everything connected with a specific contact would show up in one place. The second "flavor" would backup all of your customizations, including custom fields, membership types, profiles, etc. -- all of the stuff you stick in apart from the contact-specific info. I'd suggest using a stable file fomat for this, such as CSV, so that this info could be backed up in one version of CiviCRM and restored in the current version.

Benefits:

1. This would make it easy and convenient to get the information out of CiviCRM for manipulation in other programs outside of CiviCRM.

2. A lot of the people who use CiviCRM are more comfortable working within the program than hacking around outside of it. If you don't know what you're doing, you can do a lot of harm by rooting around in your MySQL file. This is particularly true with a complex program like CiviCRM.

3. If somebody misses a few upgrades, this could provide a direct path for upgrading to the newest version, rather than having to install and uninstall each upgrade you've missed so you can run the database upgrade utility.

I wish I had the skills to make this happen, but I'm afraid my programming experience is limited to a bit of hacking around with Basic and Fortran decades ago. Still, I figured I'd throw the idea out there in the hope that it would catch somebody's eye. Being able to backup and restore data seems like such a basic function that I'm surprised it's not already a part of the program.

My thinking in separating "contact data" and "customized data" is that the former probably changes a lot more often than the latter. Once I've built the "structure" by creating custom fields, membership categories, profiles, etc., odds are pretty good that I'll mostly leave that alone unless there are structural changes in my organization that need to be reflected in the structure of my database. But I'll probably change individual user records every day. Breaking out the contact-specific information would make it less of a chore to backup my user data, and on those occasions when I've made structural changes I could do a fresh backup of that part of things. I understand that a lot of the contact data is useless without the customized data, but because it changes less often it could probably be backed up less often.

In the event of catastrophic failure of some kind, I could just install the most current version of CiviCRM, then install my most recent "customized data" file, and then dump my user data back in. Having two backup files to restore would still be a lot easier than having to deal with the many interrelated tables in a CiviCRM installation -- especially for a person without much MySQL experience (probably most folks who use the program).

Hopefuly so. In my admittedly uninformed opinion, it probably wouldn't be terribly difficult. It seems like it would largely be a question of being able to grab the right tables in the right order, and then being able to reverse the process, all from within CiviCRM. But there would also be an ongoing task of keeping up with schema changes as the program continues to grow and improve.