Chris,

The import_export extension[1] captures every model in the database within one big yaml file. By default this is saved as db/export.yml.

Pros:
* very portable

Cons:
* if you want to edit the records captured in the yaml, they can be quite difficult to find


The super_export extension[2] captures every model in the database in its own file. The file format is like this:

        /db/export/:model_name/:id.yml

Pros:
* it is easier to locate individual records, should you want to edit them

Cons:
* less portable export format than a single yaml file

There is no harm in installing both extensions, playing around with them and deciding which you prefer. They can both co-exist happily. Of course, things could get confusing if you keep a stale db copy in one format...

If your assets are stored on the filesystem, then neither of these extensions will be able to assist in backing them up. I don't know how they would fare if you were storing your assets in the db...

I hope that helps.

Cheers,
Drew


[1]: http://github.com/radiant/radiant-import-export-extension/tree/master
[2]: http://github.com/Aissac/radiant-super-export-extension/tree/master


On 13 Nov 2008, at 22:00, Chris Parrish wrote:

One of the problems with Radiant being so extensible is that it attracts a lot of software geek-types. ;-) It's no issue for me to do a db dump/restore but I couldn't give that job to my assistant.

Plus I'm not sure that that's a friendly format for, say, version controlling a site's content.

Anyway, sorry for not being more clear. My goals here are:

  * It's simple (read: non-technical users love it)
  * It's db-independent so if my local development environment is
    Sqlite3 but my server is MySQL or PostgreSQL (or I want to change
    databases/servers some day) it's no sweat to move content around.
  * It's collects all of the content (this means styles and scripts
ala SnS, and whatever fun extensions I choose to add in the future).
  * My site's content can be fully restored via import.
  * Ideally it's in a human readable format so if it's kept in an scm,
    diff tools can identify changes.
  * Bonus points for packaging all the files up nicely (like a zip or
    tarball for download).
  * Bonus points for managing asset files such as images images
    (though I'm not holding my breath here).

And I'd really *love* it if someone could tell me the difference between import_export and super_export (which I think does import too).

-Chris


Mohit Sindhwani wrote:
Chris Parrish wrote:
I'm looking for a good way to backup/restore all of my content for a Radiant App. I'm want something that collects all the data (including extension models).

I'm aware of Import-Export and Super Import-Export but I can't seem to find anything that clearly spells out the differences. Is anyone familiar with both solutions (or any other ones you'd recommend)? I could use some tips.
Would a database dump not help? So far, I'm using SQLite, so I just move the database between my PC and the demo site. But, I would have thought that a database dump would manage 'almost' everything. The only thing that gets left behind, unfortunately, is the stuff in public... and I don't know how Page Attachments / Gallery would work across database dumps and restores.

I need to think about this not too far in the future... in a way, it's good that you're ahead!

Cheers,
Mohit.
11/14/2008 | 2:58 AM.

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to