Mgmt command to load initial data and images about bakerydemo HOT 11 CLOSED

The stub exists here: https://github.com/wagtail/bakerydemo/blob/master/bakerydemo/base/management/commands/load_initial_data.py

from bakerydemo.

Just had a thought, curious about your opinions:

I can't think of a good reason why dumpdata/loaddata and a data loading management command would be better than a simple sql dump/import. This is a case where we don't need to worry about preserving a pre-existing db. Given the challenges during the sprint of getting all of the dumpdata apps in the correct order, it seems more complex and somewhat fragile to use that standard approach.

What if - and I'm just thinking out loud here - the readme did NOT include instructions to migrate, but instead, simply:

cat dumpfile.sql | sqlite3 bakerydemodb

I've tested this and it works perfectly, using a dumpfile created with:

echo '.dump' | sqlite3 bakerydemodb > dumpfile.sql

We would have a parallel psql instruction for postgres users.

This technique has the added advantage that it becomes really easy to guarantee a full and perfect db for everyone, no chance of anything missing. And if we ever modify / edit the db contents, it becomes super easy to replace data set with a new one in version control.

I know this is a bit unorthodox in Django, but it's feeling sensible to me for this use case. Thoughts @daaray @heymonkeyriot ?

from bakerydemo.

I am in favor of sticking with the management command for a few reasons:

• It does keep with the convention seen in most other projects in the Django community
• It doesn't require different instructions dependent on the database the user elects to use
• It would require two commands to perform a load (the SQL import and a separate command to load images)

from bakerydemo.

Actually it dawned on me this morning that it wouldn't need any command for sqlite users - we just include the sqlite in the repo since it's just a file! No export or import of any kind needed. And why do the images need a loader? They can just be checked in right where they sit.

from bakerydemo.

Ah, I thought we were still wrestling with putting images in the repo or on S3 as a zip.

from bakerydemo.

It's still a legit question (where to put images), partially dependent on the final size of them all. We'll have quite a few. My original_images directory is currently 18.6MBs, but its contents are fairly "accidental" at the moment - not carefully chosen and not specifically optimized. The question I guess is "what do we gain by having the images live externally?" The user has to download the same amount of data either way. By making it external, they have two downloads and an import process; by including them, things are simplified. I'm all for user simplicity. What are the arguments in favor of having images live externally?

@tomdyson Any thoughts on image inclusion in the repo and/or just packaging the sqlite db itself in version control? (vs. packaging the images as an external zip and requiring a loaddata command for the data)?

from bakerydemo.

(Sorry feel like I missed the conversation here)
If we need some sort of import I'm also very much on the side of having a management command for the reasons that @daaray makes. Additionally I like the active nature of it, I think it's a positive thing that the user is actively populating their Wagtail installation, it's closer to the reality of a Wagtail project rather than having it there to begin with.

The problem with having images in the repo is that once they're there they'll be there forever. If, for whatever reason, we decided we wanted to change the images we'd be inflating the repo continually. A very minor thing, but it'd also mean a user who's just wanting the repo to look at the code will be made to download irrelevant content.

That said hosting the images externally will be a bit of maintenance pain; I can see that it would certainly be simpler to have them in the repo.

from bakerydemo.

For images, how about this? Since it would be great to be able to use github rather than an external neutral host like S3, but we also don't want the code repo to grow without shrinking (solutions to prune deleted images from repos are byzantine), how about this?

1. Create a new/separate github repo bakerydemo_images
2. Data is preconfigured (normally) to look for images in bakerydemo/media/original_images
3. The data loader management command uses a workflow something like this:
   • cd bakerydemo/media
   • git clone https://github.com/wagtail/bakerydemo_images.git original_images
   • cd {project_root}
   • call_command loadddata foo bar baz

from bakerydemo.

To truly avoid the problem of the repo growing we'd need to not use github. I'm sure any of us can provide hosting space for a .zip , but it should be neutral, not attached to any of us. I'm having trouble thinking of a hosting space that's neutral, respected, and free. Anyone?

from bakerydemo.

The data loader should also include delete from wagtailimages_rendition; so we don't have to remember to do it manually every time.

from bakerydemo.

Sorted!

from bakerydemo.