9

For example, say I am working on a FAQ page locally. I create whatever plugins/templates etc I need. Then, locally, I proceed to add the plugins to the page, debug, modify whatever. Now it comes time for me to deploy this to production.

I am left with redoing all the work again, copy/pasting the content and rebuilding the FAQ page or is there an alternative way? Things I have thought of:

  • Create a data migration representing the structure/content

  • Sync the production db to the dev db, make my changes and push it all back during a downtime window.

Are there any other solutions around in the Django CMS community for handling this kind of thing?

The data migration seems like the best approach, but I figured I would ask to be sure I wasn't missing anything.

AJ Venturella
  • 4,742
  • 4
  • 33
  • 62
  • This is what I'd like to know, too. I dumped the data from the database and loaded on the server, copied the `media` directory, but couldn't recreate the plugins with files. Further problems are the apphooks, which I couldn't transfer or attach programmatically. So, you are not alone! – cezar Oct 04 '17 at 12:56

1 Answers1

5

I am not aware of any out-of-the-box solution to this problem. Data migration seems fine, though if you are planning to integrate it into the actual migrations framework, I would be worried about making it too coupled to the state of the database (i.e. if you are inserting the content into a specific page ID).

What we have been doing in our projects is to create as special app that provides additional commands for the management CLI. You can then keep the migrations separate from data population. Once you deploy your plugin structure live, you can simply run a command to populate the database.

After you have seeded the data, you can simply disable / completely remove the temporary app without having any effect on your main application - compared to keeping tightly coupled data population in the migrations framework, that wastes both space and tightly couples the db migration to your db contents.

petr
  • 2,554
  • 3
  • 20
  • 29
  • Do you script it in a formal data migration or do something akin to dumpdata (not actually dumpdata) just some serialized format that you can reconstitute and replay? – AJ Venturella Oct 06 '17 at 12:11
  • 1
    Actually, I would use the abstraction - as you know what the fields of the plugins are in advance, you can iterate over placeholder contents and then create new CMSPlugin instances with the correct relationships etc. Though I can imagine that for a one-off, that may be a bit too much work and more direct serialisation would suffice – petr Oct 06 '17 at 12:14
  • Ya, that flow is exactly what I have been working on. Good to see the validation. Iterating the placeholders, and rebuilding the plugins on the target. – AJ Venturella Oct 06 '17 at 12:16
  • 1
    I usually prefer that way - as that ensures that all code triggers are executed etc - and it's usually easier than being _really_ sure that surgical extract and transplant of data into a different db is going to work – petr Oct 06 '17 at 12:17
  • What if you want to migrate a whole page with an apphook attached to it? What about uploaded files, let's say for image or carousel plugins? How would you assure they are properly transfered? Also I'd like to see as a minimal example how a placeholder, with all plugins and contents, could be programmatically moved to another DB. – cezar Oct 06 '17 at 12:21
  • 1
    @cezar That would ultimately be similar approach, just would require more research to get the right classes out of Django CMS packages for instantiation. Re. migration of media library - to be as universal as possible, you would need to split this into two steps: 1. Build source-side migration script to copy media to a folder / URL 2. Populate the media library target-side and store a mapping between new path and original identifer 3. Populate the target fields with the above This is the same for any foreign keys / relations. – petr Oct 06 '17 at 12:27
  • I've done something similar a while back, the difference here being that I was migrating within a single database between plugin models. An additional step of storing those values + restoring on target would be needed when moving between DBs https://gist.github.com/petrklus/0d2e38894fea39bbff0b6f42655676a8 – petr Oct 06 '17 at 12:29