Comments (11)
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?
- Create a new/separate github repo
bakerydemo_images
- Data is preconfigured (normally) to look for images in
bakerydemo/media/original_images
- 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.
Related Issues (20)
- CSP testing setup HOT 9
- Create separate `dev` branch for Wagtail development purposes HOT 2
- modelcluster. ValueError : invalid literal for int() with base 10: 'THU' on locations pages in the admin preview HOT 1
- Inaccurate copyright message in footer HOT 1
- Documents in demo site HOT 1
- Replace ModelAdmin usage with snippets
- MultipleChooserPanel example
- Issues with loading initial data (SearchPromotion)
- Create (or change) a model to use UUID/non-integer for its primary key HOT 2
- Help text of featured sections in homepage repeats the same as in Promo title
- Guys, it uses so old packages. and gives error. I recommend don't use this demo. HOT 1
- Images in all of Wagtail’s supported formats
- Enable `USE_THOUSANDS_SEPARATOR` by default & have some larger test ids HOT 3
- Update Node/NPM libraries (Node 20)
- AttributeError: module 'dotenv' has no attribute 'read_dotenv'. Did you mean: 'load_dotenv'? HOT 3
- exec /code/docker-entrypoint.sh: no such file or directory HOT 2
- migration failed HOT 1
- Fresh install of the bakerydemo using pyenv generates 'KeyError at / <wagtail.images.models.Filter object at 0x10953ef40>' HOT 11
- Fix all remaining design and coding accessibility issues HOT 2
- Cannot run example through Gitpod HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bakerydemo.