cubicweb #1768109 [migration] add_cube will create missing entities from unrelated cubes [deprecated]
suppose cube cube_A depends on cube_B. You want to migrate cube_A from version 1 to version 2, and cube_B from version 10 to 11. cube_B-11 introduces a new dependency on cube_C, and cube_A-2 adds a new etype. cubicweb-ctl upgrade will run the cube_B migration script which will execute add_cube('cube_C'). This action will as a side effect create the the new etype (and probably the new rtypes and rdefs) introduced by cube_A-2 (depending on the location of the add_cube call in the migration script, the same thing will happen for new schema objects strictly belonging to cube_B-11). The consequence is that the traditional unguarded calls to add_entity_type (resp add_relation_definition, etc.) in the cube_A-2 migration script will fail because the etypes already exist in the schema. | |
priority | important |
---|---|
type | bug |
done in | 3.16.1 |
load | 0.000 |
load left | 0.000 |
closed by | <not specified> |
- cubicweb #473794 when an entity type is renamed, physical db index should be renamed as well
- cubicweb #506878 rename schema/ and entities/
- cubicweb #2167873 ease static data/ directory handling
- cubicweb #890167 [win32/service] ctl migrate does not handle service mode
- cubicweb #1113844 Migration script function to reindex a given entity
Comments
-
2013/02/19 11:16, written by acampeas
-
2013/02/20 09:27, written by sthenault
-
2013/02/20 09:34, written by acampeas
-
2013/02/20 09:53, written by sthenault
add commentIsn't that solved ? I believe as of today the schema "add" ops won't stop if the things are already known.
indeed. Though the pb described here is rather that "add_cube(toto)" may add stuff totaly unrelated to the "toto" cube.
That "add_cube('foo')" adds stuff unrelated to the 'foo' cube is quite expected (as per the scenario above). I will close the ticket.
imo this is a bug, even if it's not easy to fix as is