Re: uuid field short websafe representation
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
>>>
>>> <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/396e017f-3c57-486c-a7d3-6d9f0a2e9d7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
uuid field short websafe representation
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.
Re: apps with the same name
What is so strange about "myapp.admin as admin" ?Users of Django are usually familiar with such syntax - SQL uses that, Python import uses that. From the user readibility I prefer it.With:
INSTALLED_APPS = ( 'foo.bar.baz', ('foo.baz.baz', 'baz2'),)you will have to deal with several brackets and explain what is the name and what the alias.Radek
On 1/19/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
On Jan 18, 2006, at 8:23 PM, Adrian Holovaty wrote:> On 1/18/06, hugo <[EMAIL PROTECTED]> wrote:>> How about something like this: INSTALLED_APPS = (
>>'foo.bar.baz',>>('foo.baz.baz', 'baz2'),>> )>> This seems to be a good compromise -- it requires no change for the> common case, and it's not "code as string" stuff. Shall we?
Sounds good to me.Jacob
Re: Failing silently, and documentation thereof
>> We really need an official Django logging frameworkIf you consider adding logging module into Django, take a look at keyword based logging. http://agiletesting.blogspot.com/2005/06/keyword-based-logging-with-py-library.htmlRadekOn 1/12/06, Simon Willison <[EMAIL PROTECTED]> wrote:On 12 Jan 2006, at 06:59, James Bennett wrote: > The Django docs say that template filters should always fail silently> and never raise exceptions; they should instead return either the> original input or an empty string, as appropriate. And when writing > template tags, the tag's render() method should fail silently as well.Thinking about this further, it could result in a security hole. If afilter that removes dangerous markup failed silently and that markup was spewed on to a page it could lead to an XSS vulnerability.We really need an official Django logging framework so stuff likethis can be logged (rather than the current email-to-adminsworkaround which doesn't scale to large deployments). Cheers,Simon
Re: Proposal: Django namespace simplification
Could you follow some uniform way of the pluralization of module names?I mean why there is django.shortcuts.views (plural) and django.form (singular)? I hate those code mistakes when just one s is forgotten. RadekOn 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:>> Let's get some more feedback quickly and move forward with this. Also,> is anybody interested in implementing this code in magic-removal? I've added a new page to the wiki [1] (and a link to that page [2])describing what decisions were made (mostly based on what Adrian said)Please check it out and modify it as necessary (I may havemisinterpreted something). I can't commit to doing the whole thing right now, but I think maybe we could just stick our name next to achange on that wiki page to claim it. I'll can on them as I get time,but I won't hold anyone else back. Will that work for everyone?Joseph [1] http://code.djangoproject.com/wiki/NamespaceSimplification[2] http://code.djangoproject.com/wiki/RemovingTheMagic
Re: GUID discussion
> Just a simple cronjob with an SQL statement that blows away outdatedsessions.Any thoughts of putting this into the bin or maintenance subdir of Django distro?Radek On 1/9/06, hugo <[EMAIL PROTECTED]> wrote: >True. The fun thing about the recipe is that it produces keys that are>so unique that they do not need to be checked against a db. That's>where the performance benefit comes from. And I think not checking >against a db is the "other context" mentioned in the ticket.Actually it doesn't. It depends on the used IP - and that doesn'tnecessarily be unique, if for example people run servers behind a front apache inside of the DMZ and use private-range addresses there. Toguarantee uniqueness you wouldn't use IP adresses but would usenamespaces - like domain names with host names where you are sure touse a domain only you control. And you want to throw in a cryptographic signature to make sure that nobody can tamper with GUIDs by just usingyour domain.Oh, and due to the added md5 hexdigest the "guaranteed uniqueness"isn't really realiable. I still remember the days when PGP switched to an extended key ID format, because the old one produced duplicates, andI still remember people to produce keys with identical fingerprint.Actually MD5 nowadays isn't really reliable anyway, so it should be used at best only for it's good bit-change-spreading behaviour (that'swhat it is used for in Django).>Where do you do session cleanup? Are you using a simple bash/cron job>or is it something that should be running within django? Just a simple cronjob with an SQL statement that blows away outdatedsessions.bye, Georg
Re: Problem with autoreloading with development server
I also get sometimes the error Eugene noted. Using Python 2.4.1 on WINXP. When dealing with autoreload, I often found that it would be usefull if the server could be forced to reload on some keystroke (eg. CTRL-R). Then I would not need autoreload at all (I rather know when things change). So I suggest both: switchable (based on command line parameter) autoreload and forcing COMMAND (CTRL) - R for manual reload Any thoughts? Radek On 12/23/05, PythonistL <[EMAIL PROTECTED]> wrote: > > Hello Eugene, > I use Python 2.3. > (You can email to me directly to my email: > PythonAThope.cz > where AT is @) > Regards, > L. > >
pluralization - was Re: Descriptors for fields?
Ie. verbose_name_plural defines the name for code (object instances)? Based on the tutorial I thought it is mostly used for admin presentation texts. Radek On 12/12/05, James Bennett <[EMAIL PROTECTED]> wrote: On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:> the issue is, how do you define the pluralization. just adding s at the end> works only in some cases and does not usually work in other languages. (eg. > in Czech: class Anketa - plural is ankety not anketas)Currently, with verbose_name_plural. Maybe something better will comealong, but again, that's a completely separate discussion.--"May the forces of evil become confused on the way to your house." -- George Carlin
Re: Descriptors for fields?
the issue is, how do you define the pluralization. just adding s at the end works only in some cases and does not usually work in other languages. (eg. in Czech: class Anketa - plural is ankety not anketas) you can imagine it with class Money() (I know, it's not very good example - we usually say price, but it is tough to show it in English.) would you state: reporter.moneys.add(...) ? RadekOn 12/12/05, James Bennett <[EMAIL PROTECTED]> wrote: On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:> so I think it should be either:> 1.>reporter.article.add(...)> article.reporter.id>> or:> 2.>reporter.articles.add(...)>articles.reporter.id>To me, the pluralization makes sense; a reporter has many articles, so 'articles' is pluralized in the 'reporter' methods. An article has onereporter, so 'reporter' is not pluralized in the 'article' methods.this is logical, and helps serve as a reminder of what context you're working in.--"May the forces of evil become confused on the way to your house." -- George Carlin
Re: Descriptors for fields?
I am fine with verbose_name etc. I meant pluralization in the code. I was confused with reporter (singular) and articles (plural, which I thought was based on class Article - singular) and thought you want to create lists based on autogenerated plural. => reporter.articles you can see it here: >>> reporter.articles.add(headline="John's second story",pub_date=datetime(2005, 7, 29))>>> article.reporter.id so I think it should be either: 1. reporter.article.add(...) article.reporter.id or: 2. reporter.articles.add(...) articles.reporter.id I guess the 1st makes more sence. RadekOn 12/12/05, James Bennett <[EMAIL PROTECTED]> wrote: On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:> very nice proposal. but please avoid pluralization. it is very odd in other> languages than English. I think pluralization is something to be dealt with elsewhere; so longas this takes advantage of module_name, verbose_name and/orverbose_name_plural (which I assume it will do) it should be OK fornow, and then if/when a decision is finally reached about how/whether to handle pluralization, it can be modified if needed.--"May the forces of evil become confused on the way to your house." -- George Carlin
Re: Descriptors for fields?
very nice proposal. but please avoid pluralization. it is very odd in other languages than English. RadekOn 12/12/05, James Bennett <[EMAIL PROTECTED]> wrote: On 12/11/05, Robert Wittams <[EMAIL PROTECTED]> wrote:> Its pretty orthogonal to most of the other suggestions.Yeah, but as proposed lookup syntaxes go, this one is by far the best. And implementing special methods like __len__ would make it just aboutperfect, IMHO; the closer we can get to models behaving like standardPython classes, the better.> However, I think using a descriptor it is possible to make the "object > manager" work in the way that people seem to want - allowing access via> the class, but not via the instance ( seperation of table wide and> instance-specific functionality.)This is pretty cool. --"May the forces of evil become confused on the way to your house." -- George Carlin
Re: Add automatic thumbnail generation to ImageFields (from ticket #961)
> thumbnails to make things more general. Thumbnails are saved in the > same directory as a original file with following filename pattern: OK, but can we make more thumbnails of different sizes from one image simultaneously? And can we add options for image decorations? (shadow, watermark, etc. that PIL allows) Radek On 12/1/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote: > > On 2005-12-01, at 17:52 CET, Radek Svarz wrote: > > > I've realized that this is becoming quite a pattern. Would this > > correlate with your approach? > > Well, no. I deliberately choose not to have any predefined size for > thumbnails to make things more general. Thumbnails are saved in the > same directory as a original file with following filename pattern: > _t[][_h]. (this is following thumbnail > naming scheme found in admin). > > --- > Nebojša Đorđević - nesh > Studio Quattro - Niš - SCG > > http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ > Registered Linux User 282159 [http://counter.li.org] > > > >
Re: Add automatic thumbnail generation to ImageFields (from ticket #961)
Hi, We have been using xt:Commerce for a while and I realized quite nice approach to organize images. There are several subfolders of media for product images, like follows: product_images/original_images product_images/thumbnail_images product_images/info_images product_images/popup_images where original images (biggest / huge / not ready to show on the web) are stored for the reference and possible recreation of other sizes under different conditions when needed. thumbnail images are list thumbnails (smallest) info images are images shown on the detail page of the product (middle size to fit the design) popup images (big size) are images, when it is clicked on the info image, so the new window with just the image opens (and closes on another click on the big image) I've realized that this is becoming quite a pattern. Would this correlate with your approach? Radek PS: look at the flickr - they have even more sizes On 12/1/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote: > > On 2005-12-01, at 16:40 CET, PythonistL wrote: > > > Please let know the Django community when you are finished with that. > > First version is attached to #961, it requires to patch django > because that is the only way for me to add some "magic" into model > delete method (see save/delete/etc hooks for custom fields thread). > > Other solution is to manually insert call to delete thumbnails in > model _post_delete method. > > If this makes into contrib I'll will have to make separate helper > function to delete thumbnails for a given image url and drop auto > deletion (for now). > > --- > Nebojša Đorđević - nesh > Studio Quattro - Niš - SCG > > http://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ > Registered Linux User 282159 [http://counter.li.org] > > > >
Re: Making Django easier to get started
Simon, you named one good metric. I.e. how long is the screencast to create an application pattern (weblog in this case) :) Another Radek On 11/21/05, Simon Willison <[EMAIL PROTECTED]> wrote: > > > On 21 Nov 2005, at 09:45, James Bennett wrote: > > > 2. Django doesn't have one of those nifty "useful application in > > twenty minutes" tutorials/screencasts. Again, I'm partial to a weblog > > as the sample app because it's stupidly easy to do in Django and shows > > off a lot of the nice built-in stuff, and having something visual that > > people can watch would go a long way toward communicating how simple > > and effective Django really is. > > If we're going to have a weblog building screencast, we should make > sure it's unbelievably short - definitely less than 5 minutes, > preferably less than 3. If you think about it a basic weblog app is > nothing more than a single simple model, the date-based generic views > and four templates. > > It would be nice if we had some way of speeding up template creation > for generic views... then we could get it down to less than a minute :) > > Cheers, > > Simon >
Re: MySQL character set problem
not sure if that helps you. We had to rollback and use 4.0.x (with win-1250 and iso-8859-2) because the support of UTF-8 and collation in 4.1 for the czech lang. was not properly done. I'll give 4.1 another try tomorrow and let you know. sorry, no help today. Radek On 11/16/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote: On 16-11-2005, at 13:12, Radek Svarz wrote:> There are diffs between 4.0.x 4.1.x and 5.My local version is MySQL 4.0.23_Debian-3ubuntu2.1-log and TextDriveis using MySQL 4.1.14-log, and probably that is a problem. Any solutions?---Nebojša Đorđević - neshStudio Quattro - Niš - SCGhttp://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/ Registered Linux User 282159 [http://counter.li.org]
Re: MySQL character set problem
What's the MySQL version? There are diffs between 4.0.x 4.1.x and 5. RadekOn 11/16/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote: I'm hitting interesting problem with MySQL hosted on TextDrive. Allcharacter encoding is set to utf-8 but I'm still getting a '?' forall accented characters from all queries.They recommended that 'SET CHARACTER SET utf8' should be sent after opening connection to counter this to force connection to use 'utf-8'.Any ideas?---Nebojša Đorđević - neshStudio Quattro - Niš - SCGhttp://djnesh.blogspot.com/ | http://djnesh-django.blogspot.com/Registered Linux User 282159 [http://counter.li.org]
Re: Dajngo wishlist
""" It seems to me that the original question here is based on a misunderstanding; """ James, you made a good point. So, when we rate it (1 best): 1 FCGI 2 mod_python 3 SCGI ? 4 Twisted X runserver (development only) X+1 CGI (probably performance worse than runserver) Is it OK for suggesting? RadekOn 11/14/05, James Bennett <[EMAIL PROTECTED]> wrote: On 11/14/05, Radek Svarz <[EMAIL PROTECTED]> wrote:> I believe that PythonistL did not asked about running it on CGI. He asked to> run it on the shared webhosting. And noted some issues. Django runs perfectly well on shared hosting. Plenty of hosts outthere offer Python/FCGI which is perfectly suitable for runningDjango, and does not require you to mess around with mod_python or thehttpd.conf file. If a host does not provide Python and FCGI, then it'stime to find a new host; there are plenty of fish in that sea.It seems to me that the original question here is based on amisunderstanding; he has an unhelpful, non-knowledgeable or unfriendly host, and is taking that to mean that Django can't run on sharedhosting.> > In short: you really don't want to run any complex web framework from a> > CGI environment. Get a decent hosting plan that includes FastCGI, SCGI, > > mod_python or user-provided daemons.Which is perfectly possible at a variety of hosts, some of which areeven documented on the Django wiki.--"May the forces of evil become confused on the way to your house." -- George Carlin
Re: Dajngo wishlist
I believe that PythonistL did not asked about running it on CGI. He asked to run it on the shared webhosting. And noted some issues. There is no reason to think about using CGI at all as many of you noted. I believe that there is / will be shared webhosting with mod_python / fastcgi support. (At least he can ask admin of LJW, who posted the offer somewhere here :) To conclude points: 1. don' t use CGI 2. mod_python on shared webhosting requires restart of Apache, when django models change in order to take effect. 3. httpd.conf on shared webhosting is not available (for custom change) If we deal with #2 and #3 Django can be more adopted. RadekOn 11/14/05, hugo <[EMAIL PROTECTED]> wrote: > ( I guess that from this:>If a Python programmer has a good webhosting ( = share webhosting)>company, he is happy with, why he should find another one only to>install Django?)Because he wouldn't be anymore happy with his webhosting, if he is forced to run Django under CGI, as that is dead slow. So if hiswebhosting doesn't provide either FastCGI, SCGI or mod_python, he wouldbe forced to find another webhosting anyway, as CGI isn't an option.The startup time for Django is just to high - and CGI will startup Django for each and every request!And even if his webhosting would only provide CGI and he would be happywith the horrible performance - as soon as the first larger hit on hisapp happens, the webhoster would throw him from their host, because those CGIs will grab much more resources than standard CGIs do.In short: you really don't want to run any complex web framework from aCGI environment. Get a decent hosting plan that includes FastCGI, SCGI, mod_python or user-provided daemons.bye, Georg
Re: Dajngo wishlist
Simon, you are saying that FastCGI serves worse than mod_python? IMHO sharedhosting is quite crucial for better Django adoption. RadekOn 11/14/05, Simon Willison <[EMAIL PROTECTED]> wrote: On 14 Nov 2005, at 16:24, PythonistL wrote:> So, would it be possible to make the installation easier also for> those who use share webhosting ?Maybe we should document Django-as-CGI, horrible though the performance will be. We can have a big performance disclaimerrecommending this as a last-ditch option.
Re: Names for Django components
OK, let me mix it: 1. Django guitar core 2. Django ORM beats 3. Django singing templates 4. Django piano admin You have it novel and self-explanatory, too :) Radek On 11/14/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote: # 1. Django guitar## 2. Django beats## 3. Django singer## 4. Django pianoNovel, for sure, but wouldn't people have a hard time rememberingwhich is which?-- Jonathan Daugherty http://www.parsed.org
Re: i18n -- let's do it!
As a tool for translators I suggest poEdit (http://www.poedit.org/). It is very comfortable editor.
Re: tracking who modified an object
This is not the solution, just a nice good practise suggestion from the Lotus Notes world: We usually use one field called $UpdatedBy that is of the "multivalue" type. Multivalue field just stores more textual values in it separated by some char. The content is e.g.: "CN=Joe Doo /O=JoesCompany" "CN=Administrator/O=SamsCompany" "CN=Radek Svarz/OU=ADCZ/O=DGRP" The last one added is the one that modified the document latest. Thus we know any person that modified the object and can track it to the past.
