uuid field short websafe representation

[Radek Svarz]

Hi, I am glad to see the UUID field coming to 1.8

Bellow is how we do it now in 1.7.

The advantages:

 - it only uses 21 chars (instead of 32)

 - chars are safe for URLs

 - uuid is created when default is called

I advocate to have the short websafe representation. What do you think?

code:

def safe_uuid():
    return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/', '_')

 

class UUIDField(CharField) :
    """
    UUIDField stored in 21 Chars
    Example: uuid = UUIDField(primary_key=True, editable=False)
    """     
    description = "UUIDField stored in 21 Chars"
    def __init__(self, *args, **kwargs):
        kwargs['max_length'] = kwargs.get('max_length', 22 )
        kwargs['default'] = safe_uuid 
        CharField.__init__(self, *args, **kwargs)
    
    def deconstruct(self):
        name, path, args, kwargs = super(UUIDField, self).deconstruct()
        return name, path, args, kwargs

Radek

[Michael Manfre]

A non-standard, compressed unique value is not a UUID. Also, this forces database backends to store the value in a string datatype and doesn't allow taking advantage of uuid specific datatypes. E.g. Postgresql couldn't use its uuid datatype. Any data can be made safe for any specific usage, e.g. URLs, but there is no reason to enforce this requirement in all uses of the data because not everyone will expose a UUID in a URL.

-1 from me.

Regards,

Michael Manfre

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

+1 to everything you said, if someone wants a "websafe" representation, they can always just manually call safe_uuid on the UUID instance.

[Radek Svarz]

Michael, Florian, I understand your remarks.

Allow me to explain more.

I do not advocate to replace the code by the one posted by me. I rather advocate to improve it.

ad 1) I just react to the current implementation, where in the case of other DBMS than PostgreSQL the hex value in 32 chars is stored. In such cases I propose to store it in a smaller amount of 21 characters. ( = storage optimization ) 

ad 2) web safe representation

The goal is to translate URLs back and forth. E.g. server.com/apiv1/client/uuid/0b043d5842ca4cab9750b705018f4a1f should allow direct mapping to the ORM object. I am not sure whether the current implementation allows that. Or at least the documentation is not clear about it.

ad >> A non-standard, compressed unique value is not a UUID.

 Base64 is just different encoding, so value wise you still get the same UUID. 

Radek

[Florian Apolloner]

Hi Radekm

On Monday, December 8, 2014 10:41:41 AM UTC+1, Radek Svarz wrote:

ad 1) I just react to the current implementation, where in the case of other DBMS than PostgreSQL the hex value in 32 chars is stored. In such cases I propose to store it in a smaller amount of 21 characters. ( = storage optimization )

 

I guess storing the raw bytes there would make sense.

ad 2) web safe representation

The goal is to translate URLs back and forth. E.g. server.com/apiv1/client/uuid/0b043d5842ca4cab9750b705018f4a1f should allow direct mapping to the ORM object. I am not sure whether the current implementation allows that. Or at least the documentation is not clear about it.

I'd expect an UUIDField to return and take UUID objects as values, or a RFC4122 compatible string representation. And regarding url safety, how is a random uuid like 729dfd34-5681-409a-8d6a-ee25b4cf3f58 not safe? The 4 byte difference to your proposed variant (the one from your server.com url) is imo not worth any hazzle (if you want you can easily strip '-').

Cheers,
Florian

[Andrey Antukh]

Hi.

2014-12-08 10:41 GMT+01:00 Radek Svarz <radek...@gmail.com>:

Michael, Florian, I understand your remarks.

Allow me to explain more.

I do not advocate to replace the code by the one posted by me. I rather advocate to improve it.

ad 1) I just react to the current implementation, where in the case of other DBMS than PostgreSQL the hex value in 32 chars is stored. In such cases I propose to store it in a smaller amount of 21 characters. ( = storage optimization ) 

As far as I know, postgresql internally stores it in binary format.

 

ad 2) web safe representation

The goal is to translate URLs back and forth. E.g. server.com/apiv1/client/uuid/0b043d5842ca4cab9750b705018f4a1f should allow direct mapping to the ORM object. I am not sure whether the current implementation allows that. Or at least the documentation is not clear about it. 

ad >> A non-standard, compressed unique value is not a UUID.

 Base64 is just different encoding, so value wise you still get the same UUID. 

In my opinon, -1.

The presentation format of uuid should not affect in any way the storage of it. Currently with backends that supports nativelly uuid types as postgresql, stores it in the most efficient way.

My two cents!

Regards.

Andrey

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/396e017f-3c57-486c-a7d3-6d9f0a2e9d7a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrey Antukh - Андрей Антух - <andrei....@kaleidos.net> / <ni...@niwi.be>

http://www.niwi.be

https://github.com/niwibe