Closed jgaehring closed 3 years ago
This is the most commonly used UUID lib for Node and Browsers:
This is the Drupal 7 uuid module https://www.drupal.org/project/uuid, we could add a UUID field in 7 and then migrate it out to the D8/9 data model which has uuid natively.
Yea, more I think about it, I think that would be required before supporting UUID's in Field Kit. Otherwise we end up with the scenario I outlined above.
I agree it's worth exploring adding UUIDs in farmOS 1.x!
Looks like it would be pretty easy to pop the D7 module that @pcambra linked to into a dev server and see what happens.
Awesome! Yea, I'd be happy to give it a go!
I expect I should have my new farmLog
implementation ready by the end of this week or beginning of next. Perhaps we could try it out together sometime around then?
Sure! Let's give it a try.
Ah... just reading a bit more...
Looks like we'll have to make changes to both farmOS (for assets) and the Log module (for logs).
UUIDs will be generated for all core entities. An API is provided for other modules to enable support for custom entities.
https://www.drupal.org/project/uuid
- Mark your entity type in hook_entity_info() that it shall have UUIDs
- In your hook_schema definition you need to put the following ...
https://www.drupal.org/node/2387671
That code is in the log
module itself (separate repo). And in the farm_asset
and farm_plan
modules.
Taxonomy terms will be covered by UUID itself because they are core entities.
Resolved by jgaehring/farmOS.js@9297da2.
As I've mentioned in #384, I'd really like to eliminate as much additional metadata as possible from
farmLog
as possible with my new implementation (see #358). Essentially, I'd like to get rid of any fields that are not included in a standard farmOS log as it is sent and received from the server. I'm obfuscating most of the metadata that's still required with symbols and non-enumerable properties, but one case where this is not practical is with thelocalID
. It's also the one piece of metadata that absolutely cannot be eliminated, since it's essential for identifying logs that have not yet been sent to the server and received anid
.The one solution to this could be with the adoption of UUID's when farmOS migrates to Drupal 8/9. If it will also allow clients to create entities over the API with a pre-existing UUID, then there is nothing stopping us from generating our own UUID's in FK, and also supplying that as the identifier the server will use.
We're a little ways off still from that being possible on the server, but I think there's nothing stopping us from adopting UUID's in FK now, so it's easier to migrate later.
I guess one problem I see, however, is with that migration itself. That is, if Field Kit has been generating and using UUID's of its own while farmOS still uses
id
's, then when FK migrates over to support farmOS 2.x, how do we migrate those UUID's? Presumably, farmOS, during its own internal migration, will assign completely separate UUID's that conflict with the ones that already exist on FK. That may be an insurmountable problem, especially since multiple devices running FK may also have different UUID's for the same logs.I think the only way this might be overcome is if farmOS 7.x-1.x allows FK to provide UUID's in addition to the
id
's that are still farmOS's primary identifier. Then when migration happens, it can choose to use that UUID if it already exists, rather than generating a fresh one.Curious what thoughts @pcambra and @mstenta have on this.