Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
This is a meta issue for completing and improving the entity API for Drupal 8.
Goals
- Complete the API (i.e. implement full CRUD)
- Improve DX (classed objects, ..)
- Full support for diverse storage engines, remote storage per entity-type.
..?
Roadmap
Step 1: The base: CRUD, classed objects based upon a defined interface
- #1184944: Make entities classed objects, introduce CRUD support
- #1277776: Add generic field/property getters/setters (with optional language support) for entities
- #1233394: [Policy, no patch] Agree on a property naming pattern
- #1346032: Ordering of hook_entity_delete() is inconsistent
- #1301106: Rely on methods to access entity properties [policy, no patch]
Step 2: Convert all entity types to classed objects:
- #1361226: Make the file entity a classed object
- #1361234: Make the node entity a classed object
- #1361232: Make the taxonomy entities classed objects
- #1361228: Make the user entity a classed object
- #1615236: Merge entity controller interfaces, document and add default entity class definition
Once the above issues are complete:
- #1618172: Remove entity_uri() in favor of EntityInterface::uri()
- #1615240: Remove entity_label() in favor of EntityInterface::label()
Rely on. Not possible, see #1551140: Remove stub entities, replace entity_create_stub_entity().entity_create()
in entity_create_stub_entity()
Step 3: Multiple controllers/decoupling: Lay the foundation for adding more entity-based functionality.
- #1302378: Use multiple specialized entity controllers
- #1596472: Replace hard coded static cache of entities with cache backends
- #1612014: Create an interface for revisionable entities
Step 4: Add further APIs around entities
- #1346214: [meta] Unified Entity Field API
- Entity Validation (based upon property level validation API)
- Entity Access API (+ property level access). #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter()
- Entity Form system. #1499596: Introduce a basic entity form controller
- #1026616: Implement an entity render controller
Misc, but major issues without any particular order:
- Implement full revision support in the database storage controller
- #1374116: Move bundle CRUD API out of Field API
- #1391694: Use type-hinting for entity-parameters
- When revisions are done ==> #1374030: Remove entity_extract_ids() now that we have proper classed entity objects
- Refactor EFQ to build upon the storage controller
- Unify the storage system (Field storage + entity storage):
- Discussion: #1497374: Switch from Field-based storage to Entity-based storage
- Related sandbox: http://drupal.org/sandbox/damz/1496468
- #1810370: Entity Translation API improvements
General sandbox:
http://drupal.org/sandbox/fago/1497344
Let’s use this issue for high-level architecture discussion and update the roadmap accordingly.
Thoughts?
Comments
Comment #0.0
fagoUpdated issue summary.
Comment #0.1
fagoUpdated issue summary.
Comment #0.2
fagoUpdated issue summary.
Comment #0.3
fagoUpdated issue summary.
Comment #1
Gábor HojtsyLooks superb. Tagging DX and D8MI.
Comment #1.0
Gábor HojtsyUpdated issue summary.
Comment #2
gddAlso tagging cmi. Looks great.
Comment #3
gddAnother thing we will want to look at is how we're going to introduce UUIDs into entities. I will probably make a new issue for that as well. I think it makes sense for this to happen after all the entities are converted maybe?
Comment #4
xjmFrom #1184944-151: Make entities classed objects, introduce CRUD support:
I don't see revision support explicitly listed above. I'm assuming it would be an additional item in step 1, before we start on the other entities?
Comment #5
tstoecklerYou're right, though, we need that to convert nodes.
Comment #6
andypostwhen re-factoring revisions take a look at #218755: Support revisions in different states
It's not much different from #1082292: Clean up/refactor revisions
Comment #6.0
andypost(xjm) Added @todos from #1184944 and added header tags.
Comment #7
xjmAlright, I moved the note about revision support up to Step 1.
Comment #8
fagoWe don't necessarily need proper revision support for being able to port nodes over, as we can just move the revision specific stuff into the controller. That way, we could focus on porting everything over first and then get revisions right.
Comment #8.0
fagoUpdated issue summary.
Comment #8.1
fagoUpdated issue summary.
Comment #9
fagoI've added follow-up issues to the summary and moved the revision-controller to the major issues without particular order.
Comment #10
xjmCross-referencing:
Comment #11
webchickI'd love to see those follow-up issues classified as major "feature requests" rather than tasks. It's not really very equitable to the rest of the team for a single initiative to block progress on all other initiatives by pushing us up over thresholds by splitting up the work into sub-issues.
Totally cool with this issue remaining a major task, though.
Comment #12
xjmAh, yes, +1 for switching them to feature requests. They are kind of bullying major tasks at the moment. :) I've switched them to feature requests for now, unless someone disagrees?
Comment #13
catchI'm fine with downgrading the individual issues from major task, but think we should open a single critical issue (not this one which is about further API additions/changes) to track them.
Converting existing entities to the new API is essential to uncover issues with what we just committed (as we found out at length with field API), and needs to happen earlier rather than later in the cycle (and it's critical to update all core entities before we get to release, so critical feels about right for that).
Comment #14
Gábor HojtsyWell, if we want to make real use of the OO API (introducing language consistently as well as adding UUID support), we should do the conversion sooner than later. So I hope it is not just done later up to the release :) Or if the OO conversion is to be delayed, we should add UUID and language with the old methods and the conversion will be just more work that way. Not sure its better in that direction.
Comment #15
catchYeah I couldn't agree more, opened #1368394: Convert all core entities to classed objects.
Comment #16
aspilicious CreditAttribution: aspilicious commentedI added #1374030: Remove entity_extract_ids() now that we have proper classed entity objects to the todo list
Comment #17
sunComment #17.0
sunAdded issue
Comment #18
yched CreditAttribution: yched commentedAdded #1374116: Move bundle CRUD API out of Field API
Comment #18.0
yched CreditAttribution: yched commentedAdded http://drupal.org/node/1374116
Comment #19
fagoAdded #1391694: Use type-hinting for entity-parameters
Comment #20
Dave ReidIt would be very nice if we could actually keep entity_label() around. It works very well as a title callback for menu router items.
Comment #21
fubhy CreditAttribution: fubhy commentedActually, I would like to keep entity_uri as well for similar reasons.
Comment #21.0
fubhy CreditAttribution: fubhy commentedadded 1391694
Comment #22
fagoI've added #1301106: Rely on methods to access entity properties [policy, no patch] to the summary.
Indeed, that could be used for term and node view pages. However, I'd still prefer renaming it to make clear people should use
$entity->label()
now. E.g. we could have entity_page_title() analogously to node_page_title(), which just calls$entity->label()
.@entity-uri: I'm not aware of any use-case for that, but if there is one I'd suggest doing the same as for the label. Add a function that's clear purpose is being a callback.
Comment #23
catchThat's recursive ;) Not that I can talk, I've marked dozens of issues duplicate of themselves...
Comment #24
fagoWell, GNU is my inspiration :D Fixed it.
Comment #25
Gábor HojtsyMove to new D8MI-meta tag.
Comment #26
Dries CreditAttribution: Dries commentedTagging.
Comment #27.0
monil-dupe CreditAttribution: monil-dupe commentedUpdated issue summary.
Comment #27.1
fagoUpdated issue summary.
Comment #27.2
fagoUpdated issue summary.
Comment #28
fagoAlso see the related discussion over at #1497374: Switch from Field-based storage to Entity-based storage
I'ved added a pointer to that issue + the according sandbox to the summary.
Comment #29
xjmCouple followups from the user conversion:
#1537434: Add type-hinting to user entities
#1537442: Rename $user->access and $user->login
Edit: I didn't know where to put these on the roadmap in the summary. :)
Comment #30
aspilicious CreditAttribution: aspilicious commentedDo we have to make an issue to convert
"field_test_create_stub_entity"
At the moment it returns a stdObject but this is incorrect. It should return a proper entity.
That also blocks some followups like remove entity_label().
Problem: it sometimes adds a version ID which is only possible for nodes.
Comment #31
plachFirst stab to the Entity form system in #1499596: Introduce a basic entity form controller. Early reviews welcome :)
Comment #31.0
plachUpdated issue summary.
Comment #32
BerdirOpened #1615236: Merge entity controller interfaces, document and add default entity class definition and added it to step #2.
Comment #32.0
BerdirUpdated issue summary.
Comment #32.1
BerdirUpdated issue summary.
Comment #32.2
catchUpdated issue summary.
Comment #32.3
catchUpdated issue summary.
Comment #32.4
plachAdded the first issue on the entiy form system.
Comment #32.5
catchUpdated issue summary.
Comment #32.6
catchUpdated issue summary.
Comment #33
sunComment #33.0
sunreferenced the entity_uri issue
Comment #33.1
steveoliver CreditAttribution: steveoliver commentedtypo
Comment #34
BerdirWe achieved almost everything of this, yay! Now we need to complete it, there's a new meta for this, see you over in #2095603: [meta] Complete Entity Field API.
Comment #35.0
(not verified) CreditAttribution: commentedUpdated issue summary