problems with UUIDs about sharetribe HOT 8 CLOSED

UUID.timestamp_create

doesn't work because virtual network interface ther e has no MAC address.... if we add info on how to set it by hand that could also do the trick but still i don't get this 22 characters limit :)

from sharetribe.

The current UUID structure is based on early decisions few years back. The research platform where Sharetribe was linked was designed to initially follow some guidelines from Open Social standard, but that was never fully implemented. I guess the UUID part was picked from there and there was a plugin that the developer of the research platform decided to use for generating the UUIDs. When we made Sharetribe independent of that platform we picked the same code in order to maintain the same logic with UUIDs. It seems that the plugin code uses MAC address somehow in seeding the values, which results part of the string being same on the same machine (and different on different machines). I don't know too much about UUID in general, so I don't know about the 22 limit making sense or this way of constructing the UUIDs.

Currently we are not tied to any other components with out UUIDs so it is possible to update that system. I would feel good if we'd be using an up to date solution for UUIDs instead of this ancient plugin code. But this hasn't been an issue for us so far so I haven't yet looked at it.

Also it's not necessary in general that we use UUIDs as person ids, and we have talked about moving to integer IDs but there's bit of work, and we haven't seen big benefits in making the move.

In other words if you want to improve this part to make it work better also in virtual network decives etc. feel free. That sounds like improvement that we can gladly include to main branch. And there's no special needs to keep 22 chars, so increasing that is possible too. It doesn't make the URLs prettier but anyway we should put the usernames there (if we're going to keep them)

from sharetribe.

thanks for reply! in UUIDs i like that once we start federating tribes across domains they could possibly come of use, simple integers in distributed scenario come useless since they just collide! i prefer using URIs but wouldn't discard UUIDs right away ;)

for pretty URLs you can take a look at:

• https://www.ruby-toolbox.com/projects/friendly_id
• http://railscasts.com/episodes/314-pretty-urls-with-friendlyid

BTW i find ruby-toolbox.com very useful resource in general :D

from sharetribe.

affects #26

from sharetribe.

Yep there are good sides in UUIDs regarding data portability. We currently have them for users but not for other resources. I think that's actually good staring point as some changes might be needed and now we can try to put things right with user UUIDs before spreading the UUID solution yet.

I also had issues with current UUID plugin in Travis (where virtual env doesn't have MAC address that the current solution used (apparently to avoid collisions). However, we need to switch from the old style rails plugin anyway and replace it with a more recent way of creating UUIDs in Ruby. I don't know yet what's the latest recommended way, but gotta do bit of research when changing this.

(My current quick fix for UUIDtools was to return always a same hard coded mac address, if no real one is available. I think yours might anyway be better, but as said we need to update the system soon anyway so both of these should work until that.)

from sharetribe.

possibly of use: https://gist.github.com/rmoriz/937739 (UUID primary keys in Rails 3)
also using: UUIDTools::UUID.random_create.to_s

from sharetribe.

yep that could be helpful, and it seems UUIDTools is still the way to go (https://github.com/sporkmonger/uuidtools), we just need to update from the old style plugin that we use to the gem version.

from sharetribe.

Closed due to inactivity

from sharetribe.