search

farmOS / field-kit

A modular, offline-first companion app to farmOS.
https://farmOS.org
GNU General Public License v3.0
60 stars 39 forks source link

Use UUID's instead of localID's #395

Closed jgaehring closed 3 years ago

jgaehring commented 4 years ago

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 the localID. 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 an id.

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.

jgaehring commented 4 years ago

This is the most commonly used UUID lib for Node and Browsers:

https://www.npmjs.com/package/uuid

pcambra commented 4 years ago

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.

jgaehring commented 4 years ago

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.

mstenta commented 4 years ago

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.

jgaehring commented 4 years ago

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?

mstenta commented 4 years ago

Sure! Let's give it a try.

mstenta commented 4 years ago

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

  1. Mark your entity type in hook_entity_info() that it shall have UUIDs
  2. 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.

jgaehring commented 3 years ago

Resolved by jgaehring/farmOS.js@9297da2.