When you add a new entity type to your feature (while one has allready been deployed), the code is trying to create all entity_types (and their tables) anew.
I think it is because the is_new property is set automatically to true when creating the EntityType and not reset for existing entity types.
Do you really want to revert eck_entity_type? (y/n): y
WD php: DatabaseSchemaObjectExistsException: Table eck_request already exists. in [error]
DatabaseSchema->createTable() (line 652 of /var/git/is/includes/database/schema.inc).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1559650.5.eck-features-revert.patch | 2.7 KB | mrfelton |
| #4 | 1559650.4-sck-features-revert.patch | 1.29 KB | mrfelton |
Comments
Comment #0.0
mojzis commentedi finally understand what is going on
Comment #1
mojzis commentedComment #2
mrfelton commentedWe are seeing a similar problem. Attempting to force revert a feature that defines an entity type results in a failure complaining that the eck_ entity table already exists. It seems like it strats trying to recreate stuff, it inserts a record in eck_entity_type, and then dies when it is unable to create the db table that already exists. The end result is a failed feature revert, and an extra line in eck_entity_type, which shows up as a duplicate entry at /admin/structure/entity-type.
Comment #3
fmizzell commentedI am a fairly new user of features, and it wasn't until recently that I realized that when a feature tries to recreate stuff in the db, it is called a 'faux feature'. Should we make eck have real features (the entity types and bundles will live purely in code)? I think that would help us fix the revert problem without having to write a lot of code that tries to figure out what has changes so it won't be recreated, etc. I would like to hear from more experience feature users on what the correct way to handle things is.
Comment #4
mrfelton commentedHere is a simple patch that sets the is_new flag correctly, ensuring that tables and rows are only recreated when needed. But, I think you are right - if these things are in the default state, they should probably only live in the code. There is actually performance merit in this approach too.
Comment #5
mrfelton commentedOk, so may have jumped the gun a bit with the last patch. This one has actually had some good testing though, and seems to do the job, ensuring that changes to properties are properly recorded and that the resulting table changes happen properly.
Comment #6
kolier commented#5 works.
A little question related:
In class DBObject->load, why not move $this->is_new = FALSE; into the condition block if ($result) {}.
Then EntityType::loadByName() and Bundle::loadByMachineName() will know it's the is_new already.
Comment #7
fmizzell commentedComment #8.0
(not verified) commentedremoved old text