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

On Saturday, December 6, 2014 6:00:58 PM UTC+1, Michael Manfre wrote:
>
> 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
>
> On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz <radek...@gmail.com 
> <javascript:>> wrote:
>
>> 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
>>
>>  -- 
>> 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 <javascript:>.
>> To post to this group, send email to django-d...@googlegroups.com 
>> <javascript:>.
>> 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
>>  
>> <https://groups.google.com/d/msgid/django-developers/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/5979f6ae-1290-4f01-b726-93b0ea7252b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to