Jump to:
| Project: | Universally Unique IDentifier |
| Version: | 7.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I feel the current 7.x-1.x branch has several major problems that I think need to be addressed:
1. UUIDs are not automatic for any entities - I believe it should, especially if we are making a generic entity module for D8 core (needs issue link)
2. This also burdens contrib maintainers who now have to add support for UUIDs for their entities with a sub-module.
3. Lookups are expensive with storing the UUIDs in separate tables. Likely in D8 we will want an {entity} table that has the following columns: type, id and uuid. That is used to join to the separate entity tables, or could start to unify more properties.
Therefore, I'm proposing to merge the work from http://drupal.org/sandbox/davereid/1119768 into an official UUID 2.x branch, which we then use to merge into core.
Comments
#1
IRC conversation from today: http://pastebin.com/LzsuRDZV
#2
sub.
#3
+1
#4
So, here is my take on this. As I mentioned on IRC the API is usable today, but not very effective. A generic entity based solution is needed. I need this to build the new version of Deploy, and so does probably other modules trying to implement this API.
So, after talking to skwashd we agreed that I should come up with some code for a more effective API. So here it is:
http://drupalcode.org/sandbox/dixon/1191326.git/tree/refs/heads/reboot
This sandbox is based on the current UUID module, but features some major changes. The UUID fields is found as a property for all entities (a column in every entity table). The new version of Deploy is currently depending on this branch!
Generic entity support
No more sub modules. Implementing the Entity API properly allowed me to strip out around 1000 lines of code! To add UUID support for an entity you only needs to implement
hook_entity_info()and set$info['uuid'] = TRUE. The UUID module it self activates UUID support on behalf of all core entities by default.The file
uuid.incprovides the generic UUID API. The fileuuid.entity.incimplements that API and extends the Entity API with useful functions:<?php
function entity_load_by_uuid($entity_type, $uuids = array(), $conditions = array(), $reset = FALSE) {}
function entity_save_by_uuid($entity_type, $entity) {}
function entity_get_id_by_uuid($entity_type, $uuids = array(), $revision = FALSE) {}
function entity_get_uuid_by_id($entity_type, $ids = array(), $revision = FALSE) {}
?>
Full test coverage
The UUID module has with this branch full test coverage for the generic API, the Entity API implementation and the sync functionality.
Added a REST resource
One of the most common use cases for UUIDs is to providing some sort of external service. So, thanks to the generic entity support it was a very easy task to provide a REST resource for generic UUID entities, making it possible to do CRUD operations on entities if you install Services. I think it makes sense to include this for the mentioned reasons. Also, the code base is still a lot smaller!
The Deploy module is depending on this resource. This sub module still needs some minor work.
General clean up
I took the opportunity to clean up some of the other API functions with more consisten naming and better documentation.
Upgrade path
I haven't looked at this yet. Shouldn't be a big problem. Will do this later this week.
#5
subscribe
#6
dependencies[] = entity
sad panda.
#7
Yeah I'm completely willing to add *optional* entity api support into my sandbox code. It should not be required in order to install UUID.
#8
Yeah, I agree actually. The only reason why the dependency is there, is because of
entity_save_by_uuid(). There are no other reason. So its very easy to make that dependency optional. I'll fix that tonight when I get home!#9
We no longer have a required dependency on Entity API.
--- a/uuid.info+++ b/uuid.info
@@ -3,5 +3,4 @@
core = 7.x
package = UUID
configure = admin/config/system/uuid
-dependencies[] = entity
files[] = uuid.test
I will now continue with the upgrade path.
#10
Happy panda.
#11
Any updates? it's been a little while. We'd love to review the latest design!
#12
subscribing
any plans to get this committed into the uuid module?
#13
Me and skwashd are working on getting this done and reviewed this week. And yes, there are some updates.
In my sandbox (where the new branch is) I've implemented support for loading entities, so that not only their primary keys are UUID, but also all their property references like uid etc. Fields is very soon supported too. Like this:
<?php$node = reset(entity_load_by_uuid('node', array($uuid));
// This gives something like the following node object:
$node->nid = 1;
$node->vid = 1;
$node->uuid = '550e8400-e29b-41d4-a716-446655440000';
$node->vuuid = '743d0565-g78b-94d3-a166-400004466554';
$node->uid = '67e6354-e29b-87f67-a617-554400446600';
$node->field_tag[LANGUAGE_NONE][0]['tid'] = '987f0575-h45b-94d3-a456-466554000044';
?>
So, we're aiming at getting this in now this week. I need this badly for the Deploy module. And it should be ready before DrupalCon in just two weeks. So I better get it done ;)
Edit: When I said "primary keys" I meant their primary UUID (and VUUID) keys. A uuid-loaded entity will always have their local primary key intact. Only references to other entities will be swapped out with UUID references instead.
#14
Clarifying the title a bit to reflect what me and skwashd have been talking about.
#15
Subscribing
#16
I merged this into the repo last night.
#17
Automatically closed -- issue fixed for 2 weeks with no activity.