Suggestion: generate IDs in the same format as UUID

[radmen]

toID() method sorts generated id and returns it in a non-uuid format (eg. 11e7-a9d1-48fb57a0-bcd7-81ecee726a36).

Once its saved in Postgres UUID column Postgres will re-format this value into UUID canonical representation (11e7a9d1-48fb-57a0-bcd7-81ecee726a36).

In terms of Postgres it doesn't matter in which format the uuid will be passed. It will accept both of them.

However, this can be a problem when generated id is used both in a Postgres DB and different storage (in my case it is Mongo).

What I'd like to suggest is to change the format of the id generated by toID() to be exact as UUID canonical representation.

[gregl83]

Ok, thanks for the suggestion!

Originally the toID method was meant more for internal stuff but also got exposed to be accessible. It represents the modified UUID (V1 parts reordered) to be monotonically increasing.

My use-case has been mostly with mariadb in which a monotonic id is persisted as a binary type. The original UUID format is still accessible via the toUUID method.

All that being said and now looking back I can see how the documentation and interface can be confusing.

Here is an example of monotonic id with the sample above:

> var mid = new MID(null, '11e7-a9d1-48fb57a0-bcd7-81ecee726a36')
undefined
> mid.toUUID()
'48fb57a0-a9d1-11e7-bcd7-81ecee726a36'
> mid.toID()
'11e7-a9d1-48fb57a0-bcd7-81ecee726a36'

Now without providing a mid as a parameter (created from new UUID):

> var mid = new MID()
undefined
> mid.toUUID()
'54e54fc0-aae0-11e7-91ed-230dbb261dbe'
> mid.toID()
'11e7-aae0-54e54fc0-91ed-230dbb261dbe'

Changing the interface is going to be a breaking v2.0.0 change which is fine if that's the route to go.

Thoughts?

[radmen]

I'd say that toID() could be removed in favor of toUUID() returning reordered UUID in it's canonical format.

[gregl83]

The toUUID method returns an universally unique identifier according to RFC 4122. Changing it to do otherwise would break semantics. Under the hood the returned UUID is using node-uuid.

I believe I understand your use-case now.

You would like to have the string version of the modified UUID ordered to be monotonically increasing which you can get with toID; however, it maintains the field separators not by character count but by the actual field values. When persisted as a type UUID it is subsequently reformatted with the expectation that value is a valid UUID.

Would persisting your monotonic-ids as binary types be an option for you?

[radmen]

When persisted as a type UUID it is subsequently reformatted with the expectation that value is a valid UUID.

That's the case. Saving result of toID() to UUID field in Postgres will reformat it (eg. 11e7-a9d1-48fb57a0-bcd7-81ecee726a36 to 11e7a9d1-48fb-57a0-bcd7-81ecee726a36).

Would persisting your monotonic-ids as binary types be an option for you?

Not really. I'd like to use string version of monotonic-id. It's easier to use and works perfectly fine with Postgres UUID field types. I think it would be nice to format output of toID() to something that matches canonical form.

The toUUID method returns an universally unique identifier according to RFC 4122. Changing it to do otherwise would break semantics. Under the hood the returned UUID is using node-uuid.

Agreed. Maybe toID() could be the one which returns monotonic-id in UUID-ish format?