3

I just remembered, while working with custom entities, that Drupal 8 was supposed to bring UUID support and replace the old "entity id" keys but then I've also noticed that the old fashioned entity id key is required by tye EntityType annotation and interestingly the UUID key is just optional.

Is this so that urls/entites are easier to remember by their "nid"?

And most importantly: should we use UUIDs or entity ids in logic and/or database operations?

Is this the final approach or we'll see entity id disappear in beta/rc/stable release?

Personally I don't see any good reason to keep using the typical serial keys when we have UUIDs now.

Improve this question
5
  • 1
    You wouldn't traditionally use a UUID as a primary key (in my experience anyway, and not just with PHP or Drupal). Pros and cons of doing so are here and more info here. Good question BTW, hoping to see a response from someone in the know
    – Clive ♦
    Commented Jan 9, 2014 at 15:37
  • "traditionally" no, but that's the thing, we should evolve the software and move to new ways of doing things. Two things that bother me are that the entity id key has to be numeric(as described in EntityType annotation class) and that Field API fields use it without an option to switch to UUID. So the UUID is basically absolutely ignored throughout the whole codebase and I assume is utlizied only by the Migration module(haven't checked that, only guess).
    – user21641
    Commented Jan 9, 2014 at 15:46
  • I meant 'traditionally' in the sense of software development in general (not Drupal). There are significant disadvantages to using large UUIDs as primary keys in databases, even with today's hardware/software, regardless of your language/platform. IDs are usually numeric so that they can be autonumbered, take up less space in the database, and can be indexed/queried more effectively. But I'm not disagreeing with you, just playing devil's advocate
    – Clive ♦
    Commented Jan 9, 2014 at 15:49
  • I'd absolutely agree with you on the "take up less space in the database" but since translatable and revisonable entities require 4 tables(I still tihnk it can be done with 2) or that Field API fields are no more shareable between bundles(which I'm totally ok with) but still take up 2 tables per field(1 is doable) this argument is invalid :)
    – user21641
    Commented Jan 9, 2014 at 15:57
  • Yep, tricky one :)
    – Clive ♦
    Commented Jan 9, 2014 at 15:59

1 Answer 1

Reset to default
1

For context and some related discussions, see #1726734 Replace serial entity IDs with UUIDs in URLs, or even globally?. There is also a related issue about using UUID's for references, which I can't find right now.

So one argument is that all URL's would then become very long, there's no user/1 anymore but user/LONG-UUID.

Another is the database performance, the primary key is the main index of every table, and making that bigger makes every change to that table more expensive. Yes, so does having 4 tables, but there's still the hope that to make that optional for non-multilingual sites. I doubt it will be possible, but we will see.

And you have to keep in mind that the storage would not only be increased by the actual field, but also every reference, so every single field table entry would then have to store the full UUID instead of the considerable shorter primary key.

And related to the issue that I can't find right now is that it would also slow down joins that involve entity tables.

That doesn't mean that it will never happen, but it has been pushed back to 9.x to be re-evaluated there.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.