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).

Comments

mojzis’s picture

Issue summary: View changes

i finally understand what is going on

mojzis’s picture

Title: feature revert - problem with table » feature cant be deployed after adding a new entity type
mrfelton’s picture

We 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.

fmizzell’s picture

I 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.

mrfelton’s picture

Status: Active » Needs review
StatusFileSize
new1.29 KB

Here 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.

mrfelton’s picture

StatusFileSize
new2.7 KB

Ok, 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.

kolier’s picture

Status: Needs review » Reviewed & tested by the community

#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.

fmizzell’s picture

Version: 7.x-2.x-dev » 7.x-2.0-rc1
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

removed old text

  • Commit 6a9d2ce on 7.x-2.x, change_paths, own_permissions, 7.x-2.x-property-widgets, 7.x-3.x, entity_reference, 7.x-3.x-settings, 7.x-2.0.x, 7.x-2.1.x authored by mrfelton, committed by fmizzell:
    #1559650 feature cant be deployed after adding a new entity type
    

  • Commit 6a9d2ce on 7.x-2.x, change_paths, own_permissions, 7.x-2.x-property-widgets, 7.x-3.x, entity_reference, 7.x-3.x-settings, 7.x-2.0.x, 7.x-2.1.x authored by mrfelton, committed by fmizzell:
    #1559650 feature cant be deployed after adding a new entity type
    

  • Commit 6a9d2ce on 7.x-2.x, 7.x-3.x, 8.x authored by mrfelton, committed by fmizzell:
    #1559650 feature cant be deployed after adding a new entity type
    

  • Commit 6a9d2ce on 7.x-2.x, 7.x-3.x, 8.x authored by mrfelton, committed by fmizzell:
    #1559650 feature cant be deployed after adding a new entity type