Problem

  • To define the bundles of an entity type, the raw configuration of another (config) entity type has to be read in manually (since ConfigEntity objects cannot be loaded within hook_entity_info()).

Goal

  • Allow one entity type to act as "bundle service/factory" for another entity type.

Details

  • To define the bundles of an entity type, we don't need the actual entities, the raw config is sufficient.
  • That's no difference to how entity types are defined today -- taxonomy_entity_info() queries the raw vocabulary data from the database. The difference with config entities is just a different storage.
  • Eventually, we should investigate whether bundles need to be defined at all, when there's a notion of ConfigEntity objects. The entity system could just simply take a reference to another entity type and retrieve the bundles when actually needed.
  • ...which in turn gets us to a true Bundle API.

Proposed solution

  1. function node_entity_info() {
  $types['node_type'] = array(
    //...
  );
  $types['node'] = array(
    //...
    'bundles' => 'node_type',
    //...
  );
  return $types;
}

Comments

moshe weitzman’s picture

moshe weitzman commented

Seems like a useful shorthand to me.

andypost’s picture

andypost
he/him
Primary language Russian
commented

Is not it a duplicate of #1763974: Convert entity type info into plugins we could use discovery methods to define this relation which probably needed for #1801304: Add Entity reference field

Also I'd like to pay attention on #1803630: Rename entity bundles to avoid confusion

andypost’s picture

andypost
he/him
Primary language Russian
commented

shortcut module could point to menu-links with this? does it makes sense?

fubhy’s picture

fubhy commented

Eventually, we should investigate whether bundles need to be defined at all, when there's a notion of ConfigEntity objects. The entity system could just simply take a reference to another entity type and retrieve the bundles when actually needed.

I am not sure if that is enough. The bundles of an entity type might be computed bundles without a UI or any other means to create them manually. Anyways, referencing a different entity type is a good idea. But it should not entirely replace the current behavior. That would be a regression.

I like the overall proposal though.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Computed bundles? I don't quite see how that would work. Isn't it that Field API + Co need a reliable, static definition of bundles, because they are attaching stored data to them and have to maintain that? If a bundle could come and go and vanish at any time, then there's no way to maintain the attached data.

I think the proper answer to that needs to be that if someone has computed bundles, then those bundles need to be properly created/updated/deleted through the corresponding API.

fubhy’s picture

fubhy commented

@sun By computed bundle I mean hard-coded, static bundles that may be defined by a module. Not dynamically computed ones. Think about the anonymous user api issue. At some point someone proposed to have a 'registered user' vs. 'anonymous user' bundle for user entities. Those two would be static, without a config entity behind them.

yched’s picture

yched commented

Note : in #1822458-1: Move dynamic parts (view modes, bundles) out of entity_info() I propose to move the list of bundles out of hook_entity_info() and into a separate method in the entity class.

Also, we do need a crud cycle on bundles - at least, some notifications that a bundle is being created / renamed / deleted. That's currently done by the entity type manually calling field_attach_create_bundle() (that in turn invokes the associated hook), but should move out of Field API into Entity API.

fago’s picture

fago
Primary language German
Location Vienna
commented

+1 for doing so. It's what I've done in entity.module for d7 also, and seems to be sane to me. Having a proper API for bundle objects also makes it a big plus.

The only thing we need to make sure is that a bundle type can act as bundle for multiple entity types. Use case: node types are bundles for comments and nodes.

@sun By computed bundle I mean hard-coded, static bundles that may be defined by a module. Not dynamically computed ones.

Then create a new entity type and provide the default config, where's the problem? It seems overkill in the first place, where is the problem or weight it adds? The only weight it adds is yet another entity type, but we get something for it: a proper bundle API that works consistently for all entity types.

Also, we do need a crud cycle on bundles - at least, some notifications that a bundle is being created / renamed / deleted. That's currently done by the entity type manually calling field_attach_create_bundle() (that in turn invokes the associated hook), but should move out of Field API into Entity API.

Exactly. And we've an API for CRUD: the entity api + notifications built in.

wundo’s picture

wundo commented

The only thing we need to make sure is that a bundle type can act as bundle for multiple entity types. Use case: node types are bundles for comments and nodes.

@fago, I don't really understand why one bundle type would need to act as a bundle for multiple entity types, could you elaborate?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Issue summary: View changes
Status: Active » Closed (duplicate)

This is all possible now and is used for all core entity types except tests using bundle_of/bundle_entity_type annotations.