Closed ghost closed 4 years ago
Looks great.
We can do an IF statement in the startup to only do merge && mergemigrations if the db doesn't exist. Also, there is a migrate.sh to do it later, when necessary. There's also a yapo-eplus.sh script which is obsolete with your startup.sh, plus the Windows counterpart should be renamed so they are similar. Will look at it later.
actually i had that if statement in there before but removed it. for now it is just the safe way to always make the migration. also yes, there is a migrate.sh, but don't forget that we are on docker here. that means NO user interaction. so no - the migrate.sh will not work in docker.
and tbh - we have a whole lot of other issues to solve before there is a need to optimize startup time on this level...
Ahh, didn't think about docker. Well (maybe only on Windows) you CAN actually open a shell to a docker image to work on it.
Anyway. It is possible to run migrate & makemigrations before running runserver. It just takes time. Also, I am thinking what to do if the database gets broken. I have had the issue twice where it wouldn't migrate due to some Django thing. I had to dump and import all the data (it worked, but when that happens, it requires user intervention).
I like docker because it makes it simple for users and works on most platforms, except a coffee maker. But it makes things a bit more complicated, especially the drive mapping which I will be reading up on because that has to be possible.
ok, these are two different issues. my bad, i got it a bit mixed up while experimenting with the dockerhub autobuild. 1.) Dockerfile and startup.sh -> these should fix the startup issue, it relocates migration to the startup. further work is needed, but as a first shot it is "good enough" 2.) other Dockerfiles, hooks, manifest a.s.o. -> those are changes necessary for building for ARM. it is a work in progress.