Re: uuid field short websafe representation

2014-12-08 Thread Andrey Antukh
Hi.

2014-12-08 10:41 GMT+01:00 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 )
>
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


> Radek
>
> On Sunday, December 7, 2014 10:16:00 AM UTC+1, Florian Apolloner wrote:
>>
>> +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  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.
 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.

>>>
>>>  --
> 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/396e017f-3c57-486c-a7d3-6d9f0a2e9d7a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух - 

Re: uuid field short websafe representation

2014-12-08 Thread 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

-- 
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/f286e13c-bca3-4a0c-a223-708af322504d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: uuid field short websafe representation

2014-12-08 Thread 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

On Sunday, December 7, 2014 10:16:00 AM UTC+1, Florian Apolloner wrote:
>
> +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  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.
>>> 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.
>>>
>>
>>

-- 
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/396e017f-3c57-486c-a7d3-6d9f0a2e9d7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: uuid field short websafe representation

2014-12-07 Thread 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.

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  > 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 .
>> 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.
>>
>
>

-- 
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.


Re: uuid field short websafe representation

2014-12-06 Thread 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

On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz  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-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/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com
> 
> .
> 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/CAGdCwBtMjX_OHTkExpd7a8o7VfnG7AvXoV64TOvhoHd2W0_AGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


uuid field short websafe representation

2014-12-06 Thread 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

-- 
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/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.