Hi. 2014-12-08 10:41 GMT+01:00 Radek Svarz <[email protected]>:
> 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 <[email protected]> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/django-developers/396e017f-3c57-486c-a7d3-6d9f0a2e9d7a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <[email protected]> / <[email protected] > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAKn%3DmOOhNpia6b2HyMapZbqrx1XJj9gKfcH5TWaunbiCJ60hSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
