Port UUID to Drupal 7

Like I said in the email, for Drupal 7 I think the route to be taken is to enable all fieldable entities to have UUID created for. That would make several core entities uuid enabled as well as enable it for other fieldable entities added by contributed modules automatically.

I'm not sure, but there might have API functions which return what entities are fieldable as well as metadata about this entity. So no need for submodules at all, since you'll have everything you need for displaying checkboxes for uses to chose what fieldable entity they want UUID created for. Nodes, taxonomy terms,
users, comments, etc are all fieldable entities in D7.

That said, I think the port to Drupal 7 will be pretty much a rewrite of the module.

Please do not do two functions. I would provide a uuid_find($uuid, $age = FIELD_LOAD_CURRENT):

$query = new EntityFieldQuery;
$results = $query
  ->fieldCondition('uuid', 'value', $uuid)
  ->age($age)
  ->execute();
if ($results) {
  list($entity_type, $stub_entities) = each($results);
  $stub_entity = reset($stub_entities);
  array_unshift($stub_entity, $entity_type);
  return $stub_entity;
}
return $results;

@skwashd Awesome! Thanks for getting the ball rolling!

I had a quick look at the module code and it's looking promising.

And thanks @chx for mentoring :)

We , as in the Drupal community need uuid module in core in Drupal 8. It's awesome someone is working on it. I would love to see a hook_init implementation that looks at the URL and if it looks like a UUID then it quickly and quietly changes the request to point to the relevant entity URI so that example.com/$uuid can work. That'd be bliss.

subscribe. I'll be downloading your code now to give it a test run. :)

One other BIG missing piece is the upgrade path. The schema is completely rewritten, so DO NOT use this module if you are upgrading a D6 site to D7. It's not ready for that yet. :)

One issue that has been discussed in IRC with skwashd and hejrocker is that switching to this new model means that a new UUID would be generated for every entity revision. This can be preferable in some scenarios I presume, however, it may also be preferable to have a canonical UUID for a particular entity, no matter it's revision. This should possibly be a option you choose on the field itself, specifying whether the UUID changes when a new revision is created. Another option would be to create a separate field type for revision UUIDs.

hi,

you should commit your module on cvs.drupal.org :p

subscribing with #11

@skwashd: I gave you commit access. Please check in your code to HEAD and make a dev release when you feel it's appropriate.

Thanks!

Subscribing

subscribe
Waiting on this issue for D7 Node export integration #1030678: Components missing from Drupal 7 version
skwashd - hopefully I'll spot you at DDU this weekend if you want to have a chat about this

@skwashd: Awesome! Thanks for working on this!

More conversations with skwashd led to a realization that using the D7 Field API for UUIDs doesn't make sense. It is equivalent of turning the node id into a field in Drupal 6. There should be a central UUID table that stores all UUIDs for all entities/bundles/vids. The only reason for implementing the D7 Field API would be for UUID references, not for storing the generated UUIDs. This is a critical task IMO, but may actually not take that much rewriting. The current field API implementation would just need to be rewritten so that those fields are actually references, and then a new schema for the UUIDs themselves written, and implementations for the entities begun.

UUID become a "value" field which depends on the proposed hidden_field widget module

Just wanted to post a BIG -1 and a warning about this. FieldAPI is a TERRIBLE place to put something that needs to act as a reliable, unique identifier for a given entity. FieldAPI imposes a huge amount of storage and structural overhead and its advantages only appear when we deal with data that needs to be edited and presented in a variety of ways on different sites.

As q0rban says, UUID references in fields make sense, just as node references in fields make sense. But moving the UUID itself into a field would be equivalent to moving nid, or uid, or cid, into a field. FieldAPI is a fine hammer, but it would be a mistake to pound this particular screw with it.

I'd also vote against having UUID be a field, it's an identifier.

More communication with skwashd in IRC. We need a uuid column and a revision_uuid column, the same way that the node table has the nid and vid columns. The uuid value will never change throughout the life of an entity. The revision_uuid will be unique for each newly created revision. This will allow you to easily query the table on either the entity uuid or the revision uuid and get exactly what you want without any surprises.

I think this issue should have mirror issue in D8 core!

IMO UUID should be tightly involved in RPC, RDF as superglobal to identify Entities and probably Fields

At first we need UUID implementation as field then module could _alter core entities to inject uuid field into core's entities

EDIT: @chx been involved in db_sequience implementation as I remember so core could get great alternative of "sequiental" identifiers as for now!!!

I also think making this a field doesn't sound like the way to go. But I don't have any sound arguments about it and am not sure on the implications it should have in practice.

For making this a single table, there are some advantages, like being able to check for duplicates and having a central place for looking and resolving to a single object. One question would be what would happen with entities that have two or more primary keys. I'm not sure fieldable entities support this, so don't know if it would be a problem.

I think we need to point the pros and cons of the approaches we can take. This would help making a design decision with less chance to regret.

That's a good point about the primary keys, they could require different schema fields for some entities.

In Deploy I used separate tables for each of the mapping (node has node_uuid, users has users_uuid, etc). This way you can deal with compound keys. I am a fan of this approach and less of a fan of the approach in #23 because it implies that everything in Drupal that needs a UUID is going to be an entity which is not going to be the case.

having uuid as field does not make it dependent on entity primary keys.

Also having ONE huge table is a performance bottleneck - mostly about that we need more JOINs and we loose ability to identify relation of record to entity (sub entity)

we may need multiple tables for different primary key types. but for now i would focus on nailing entities and thats it. all core entities have a single int ID so lets stick to one table at first. My .02

Interesting discussion...subscribing

For other modules to rely on this port in a non-field usage, it does not make sense to have people have to install hidden_field. :/

Subscribing.

subscribing

+1

subscribe

hi,

just to let know I ve started a new project around data importing and Id stuff...

http://drupal.org/project/datasources

+1

suscribing

+1

Subscribing.

Subscribing...

You've forgotten to delete dlm funcition, so install fails and no indexes are created and vuuid field is not added to node_revision table.

I've also changed a minor error intializing schema in hook_install.

Now node_uuid works.

In order to let node creation from other sources (i.e. a Mobile phone app), i think it's necessary to check if uuid is already generated. Right now, in that situation, hook_node_presave overwrites it so I've add that comprobation.

On a different topic, @skwashd could you explain the need to track deleted items?

In addition, I've been checking uuid.inc and I think it would be better to rename $callback static variable into a more specific name, maybe $uuid_callback, to prevent possible conflicts with other modules.

Other thing I would like to know is where $generators[$generator] is declared and assigned, because I can't find it, and I don't know if could be an error.

Just a note that I'm experimenting with an entity-only UUID module for D7 originally based off skwashd's github code. I put it into a sandbox at http://drupal.org/sandbox/davereid/1119768

@skwashd and I have had an IRC talk today where I explain him the necessity of letting node uuid to be generated before node_save call. In cases where you have to sync different sources of data, ie a Drupal Web and a Mobile app in which nodes/files/etc could be generated in both contexts, the best way is to generate the UUID in the source and then export it.

As it is implemented right now, it will be overwritten.

I agree with jherencia that if a node is saved with an already existing UUID, then it should retain that UUID rather than having it be replaced. The whole idea of being able to synch content between instances of Drupal relies on this functionality.

It looks good, I'll test it later and give you feedback here.

Great work!

There is a bug with uuid_file, this patch fixes it. I've tested uuid_node, uuid_user, uuid_file + patch and they all work as expected.

I change the status till the patch is commited.

Wrong attachment.

Ok, I hope this is the last comment... lol

@skwashd function uuid_file_file_presave still comprobates if the fid is set, not the uuid.

I think it is time to move the repo to Drupal and create here the branch, that way more people could test and create possible new issues.

+1

Subscribing

I noticed some minor bugs still exist, so while we have still issue active, I wont create a new issue each time I find a bug.

I created a sandbox project for my commits for UUID which is located: http://drupal.org/sandbox/googletorp/1137642

And I have a dedicated branch for all the port fixes: http://drupalcode.org/sandbox/googletorp/1137642.git/shortlog/refs/heads... which currently only have a permission bugfix/improvement.

Will try to post here, if I'm able to find and fix more stuff.

Cool! Nice work @skwashd!

Sorry, what ticket is the work for this continuing in?