[PATCH] [fix] allow to run migrations of CW database before 3.24
denis.laxalde at logilab.fr
Tue Jun 4 10:17:10 CEST 2019
Laurent Peuch a écrit :
> On Wed, May 29, 2019 at 11:01:00AM +0200, Denis Laxalde wrote:
> > Laurent Peuch a écrit :
> > > # HG changeset patch
> > > # User Laurent Peuch <cortex at worlddomination.be>
> > > # Date 1559087484 -7200
> > > # Wed May 29 01:51:24 2019 +0200
> > > # Node ID 580c0a8681050ed789fbe1837c6cf2b9f45f9a21
> > > # Parent 6b314fc558ed33e09ff453053c6d0097e6232f95
> > > [fix] allow to run migrations of CW database before 3.24
> > >
> > > The big problem is that in 3.24 the "asource" column of entities has been
> > > removed from the database schema. This is not a problem in itself, the problem
> > > is that some migration operation like "add_attribute" will modify the entities
> > > columns and past 3.24 will try to insert values without the asource column (as
> > > expected) but ... if you are migrating an old DB, you'll still have this
> > > asource column and this "add_attribute" (or other similar operations) will
> > > fails because "asource" is a non-null column and "add_attribute" won't provide
> > > a value for it anymore.
> > I don't understand how this would happen. In changeset 054a947b5415
> > (linked below), there's a migration step doing 'ALTER TABLE entities
> > DROP COLUMN asource'. So the column shouldn't be there anymore.
> > Or am I missing something?
> Indeed, it's quite a mixed of different issues:
> * indeed asource is droped in 3.24
> * but, all the operation that works on the entities table are modified
> and will work *without* asource in ALL situations
> By consequence, if you try to run a migration before 3.24 that works
> on the entities table, CW code will generate SQL queries that don't
> take the "asource" column into account (because this has been removed
> from all the code without taking into account if the 3.24 migration
> has been run or not) and since "asource" can't be null, sql
> constrains fail and the migration can't run.
> So it's really a story about desynchronisation between how CW
> generates queries regarding the entities table after this changeset
> and if the 3.24 migration has been run or not :/
I'm afraid I still don't understand the issue. Perhaps somebody else can
take a look?
What do you mean by "if the 3.24 migration has been run or not"? Surely,
if one does not run that migration, they might get into troubles
As far as I know, when one upgrades an instance, the cubicweb migration
is first run (after bootstrap-migration stuffs) and then cubes'
migrations are run. So by having cubicweb 3.24 migration run, "asource"
column will get dropped and then all SQL queries from cubes' migrations
should account for "entities" table change and be correct.
Do you have a concrete example of this issue?
More information about the cubicweb-devel