First of all, great work on the first work version, it works pretty nice already!
However, there's an annoying caveat and that's the field definition of items_target_id.
I currently have a setup where I have one queue referencing content, and another queue (with 6 subqueues) which should be able to reference block. However, their id's are uuids, so when trying to save, the storage goes boom. The quick fix was to manually change the column to a varchar and then everything was fine.
Now, I haven't tested this, and didn't look into the details when the field is made, but in case I would have done the setup the other way around (so first reference a block, and then another queue referencing content), maybe the field would have been a string already, but not sure.
Not sure what the best solution would be here:
- a different entity reference item field per queue ?
- or maybe entity queue should provide a field extending on EntityReferenceItem so that propertyDefinitions always creates a string items_target_id field ?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2634154.patch | 929 bytes | amateescu |
Comments
Comment #2
swentel commentedComment #3
swentel commentedComment #4
amateescu commentedIt's not really necessary to provide our own special entity reference field, we can just default to a target entity type that uses string IDs in
EntitySubqueue::baseFieldDefinitions()and this will force the entity storage initialization to use a string type for the 'target_id' column :)And just as a reference note for existing D8 sites that already have this problem: you can just change the column type manually from
inttovarchar(255)for the items_target_id column in the entity_subqueue__items table.