On Mon, 10 Oct 2016 12:47:11 Mark Hatle wrote:
> On 10/10/16 12:37 PM, Paul Eggleton wrote:
> > On Mon, 10 Oct 2016 04:48:41 Hatle, Mark wrote:
> >>> On Oct 10, 2016, at 2:54 AM, Paul Eggleton
> >>> <paul.eggle...@linux.intel.com>
> >>>
> >>> wrote:
> >>>> On Fri, 07 Oct 2016 13:20:50 Mark Hatle wrote:
> >>>> FYI, I have made sure these are re-based on top of paule/django18 and
> >>>> pushed to:
> >>>>
> >>>> git://git.yoctoproject.org/layerindex-web mhatle/django18
> >>>>
> >>>> BTW for me upgrading from paule/django18 to this version. I only had
> >>>> to
> >>>> run 'manage.py syncdb'.
> >>>>
> >>>> This created the new database and added the missing field for the
> >>>> recommend.>
> >>>
> >>> I'm not sure how that worked there but it doesn't work here. If I take a
> >>> database that works on paule/django18, run syncdb then open the admin
> >>
> >>> interface and click on "Layer branches" I get:
> >> We found a severe lack of instructions for creating migrations. There
> >> were
> >> instructions for adding and deleting full DBs but not changing them. We
> >> will need pointers or help to resolve this.
> >>
> >>> no such column: layerindex_layerbranch.collection
> >>
> >> I never got that, but I'm also running SQLite. May be the difference.
> >
> > I'm using sqlite here also.
> >
> >>> I'm afraid we really do need to create migrations whenever we change the
> >>> models.
> >>
> >> Based on your prior comments we failed to find ANY reasonable examples,
> >> docs or instructions on doing this. So we are stuck without help.
> >
> > I'm happy to help directly if needed, but did you come across this
> > already?
> >
> > https://docs.djangoproject.com/en/1.8/topics/migrations/
>
> Unfortunately that is the exactly document I was looking at and could not
> figure it out.
>
> I can the various commands, makemigrations and related.. and the system
> simply told me "no migrations necessary".. and didn't generate any.
>
> So we were never able to figure out what a migration should look like or how
> to generate it.
>
> If you (or someone else) can help us figure out how to create a migration, I
> suspect after the first one --- future ones will be much easier to
> generate.
OK, so here's a step-by-step procedure - I suspect you'll need to stash and
unstash your config changes along the way as well:
1) Ensure you are using a database created at the place you want to start,
i.e. in this case paule/django18.
2) Determine which commits make changes to the models. This is one easy way:
$ git log -p paule/django18..mhatle/django18 layerindex/models.py
3) We don't have an initial migration, so we need to create that first in a
single commit before all of the others, so to do that we'll direct the rebase
to edit the top commit on paule/django18 but instead of modifying that we
insert a commit after it. We also want to edit each commit found in step 1
that made changes so we can add the migrations to them.
$ git checkout mhatle/django18
$ git rebase -i paule/django18^
(now set the command to "e" on the oldest commit, in this case 6f8201fe, and
do the same for all the commits you found in step 1, then save & quit the
editor)
4) Create the initial migration:
$ python3 manage.py makemigrations layerindex
Migrations for 'layerindex':
0001_initial.py:
- Create model BBAppend
- Create model BBClass
- Create model Branch
- Create model LayerBranch
- Create model LayerDependency
- Create model LayerItem
- Create model LayerMaintainer
- Create model LayerNote
- Create model Machine
- Create model PythonEnvironment
- Create model Recipe
- Create model RecipeChange
- Create model RecipeChangeset
- Create model RecipeFileDependency
- Create model ClassicRecipe
- Add field recipe to recipefiledependency
- Add field changeset to recipechange
- Add field recipe to recipechange
- Add field layerbranch to recipe
- Add field dependency to layerdependency
- Add field layerbranch to layerdependency
- Add field layer to layerbranch
- Add field update_environment to branch
- Add field layerbranch to bbclass
- Add field layerbranch to bbappend
- Add field cover_layerbranch to classicrecipe
5) Apply the migrations to the database - this time we make it "fake" because
the tables already exist:
$ python manage.py migrate layerindex --fake-initial
6) Create the initial migrations commit. (We won't need to do this ever again)
$ git add layerindex/migrations/
$ git commit
7) Continue the rebase:
$ git rebase --continue
8) Create the migration for the changes in this commit:
$ python manage.py makemigrations layerindex
Migrations for 'layerindex':
0002_distro.py:
- Create model Distro
9) Apply the migrations (*not* fake this time):
$ python manage.py migrate layerindex
10) Amend the migrations to the current commit:
$ git add layerindex/migrations/
$ git commit --amend
11) Continue the rebase:
$ git rebase --continue
12) Repeat steps 8-11 until the rebase finishes.
That should do it. It gets more complicated if you rename columns, or
introduce columns that need initial data beyond a simple default, split models
etc. but in this case when you're simply adding or removing columns it will
take care of creating the migrations for you as long as you know the steps
(and I admit it's a bit awkward if you've never done it before - I have the
advantage of having done this already, not exactly with Django's migrations
but with South and that was pretty similar).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
