Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flip the native and abstracted data structures for core entities #1652

Closed
mikemccaffrey opened this issue Feb 23, 2016 · 2 comments
Closed

Comments

@mikemccaffrey
Copy link

It seems like Drupal 8 missed out on an opportunity to greatly clarify the architecture of entities by flipping the data structure and abstractions. Instead of class-specific identifiers for common properties (nid, uid, tid...), all of the entities should have called common properties the same thing (id).

And then instead of having an abstraction layer to standardize the data model, have a standard data model as the core, and provide an abstraction layer for backwards compatibility. So if you go looking for $node->nid, it returns the value of the id property.

@quicksketch
Copy link
Member

So if you go looking for $node->nid, it returns the value of the id property.

This is possible but I've been leery of it in the past. In order to do this, you'd need to use PHP's magic methods for __get() and __set(). The node object wouldn't actually have a "nid" property at all, but when checked or set, the magic methods would get called and route to the property that actually does exist.

I've got two issues in particular:

  • They're called "magic methods" for a reason, they're not particularly intuitive. It can be confusing when you $print->nid and get a value, but when you print_r($node) there is no nid value.
  • Using magic methods for get/set probably has some overhead associated with it. If it were used extensively, we could introduce performance issues that would be impossible if we only used real properties instead of magically mapped ones.

Somewhat less of an issue but still a concern, right now our internal properties have at least a small amount of indication as to what they are (nid, tid, uid, etc) and these are mapped in database columns. If we just made everything "id", you'd expect the database columns to match. But that would have problems where tables need multiple IDs, e.g. the taxonomy_index table has both nid and tid. So ultimately, you'd probably leave the database schema alone, but then need to deal with mapping the id property to whatever it is in the database.

@ghost
Copy link

ghost commented Sep 27, 2019

I'm going to take a gamble and close this due to lack of consensus and interest. But do feel free to re-open (preferably with the 'needs feedback' label) if you'd like to discuss further.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants