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 o
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. ( =
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
+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
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.
UR
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:
>
