Re: +1 on part of #1810 (put parse_dsn() in django.conf)
My issue with adding DSN support to Django isn't that its not useful to some people, but that it feels like we are adding functionality that belongs in the DB-API layer, not Django. In an ideal world, the database settings would just be passed verbatim to the connect() function of the appropriate DB backend. Unfortunately, this is the one function in DB-API that varies among providers so there is no standard syntax. Some implementations support a DSN argument and others don't. It seems like for every objection to the current feature (reusing existing environment variables, supporting "standard" DSNs, securing passwords) there is a simple, reasonable solution, (albeit one that may require writing a few lines of code) yet some people don't find that satisfactory. There are lots of useful snippets on the Django project site that aren't part of the official distribution. Couldn't someone just post the parse_dsn code there and let it bake for a while? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
streaming patches reloaded
Hi folks. Following this thread ( http://groups.google.com/group/django-developers/browse_frm/thread/a0ae32019bb02f05/2c05c5363516ea76?q=streaming&rnum=2#2c05c5363516ea76) , since I can't reply there ( over 30 days old, google tells me). I have an app that uploads a 4mb file and is taking a ton of memory. >From tickets 1484/1569 they are set as fixed, but I cannot find them on django's source code. Are these patches active in trunk? If not, anyones knows if they're working after the merge? Anyone using them? Thanks a lot, arthur --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: streaming patches reloaded
On 5/12/06, arthur debert <[EMAIL PROTECTED]> wrote: > I have an app that uploads a 4mb file and is taking a ton of memory. > >From tickets 1484/1569 they are set as fixed, but I cannot find them on > django's source code. Are these patches active in trunk? If not, > anyones knows if they're working after the merge? Anyone using them? #1569 is marked as fixed, but it's for streaming *download*, not streaming upload. #1484 is for upload, and is still marked as 'new'. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: streaming patches reloaded
arthur debert wrote: >I have an app that uploads a 4mb file and is taking a ton of memory. >>From tickets 1484/1569 they are set as fixed, but I cannot find them on >django's source code. Are these patches active in trunk? If not, >anyones knows if they're working after the merge? Anyone using them? > > 1569 is applied to the current trunk. As for 1484 I use Django with it (which is not surprising since I wrote it :-) ) and I don't encounter any problems with form uploads, be it with files or not. My guess is that the main thing that holds this patch from checking in is lack of documentation and tests. But I dont' feel myself confident to do either thing being not native English speaker and not very experienced test writer. Anyone? Two things need to be documented there: - new boolean setting "STORE_UPLOAD_ON_DISK" - new key for request.FILES items: item['file'] which is a file-like object for accessing uploaded file. The old way item['content'] still works loading file in memory on first access. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
template loaders
Moving closer to portable Django apps I decided to relocate template files from djangoprojectroot/templates/APP/ to djangoprojectroot/APP/templates/ I like it better because it keeps all APP-related files together. Immediately I encountered three problems: 1) Before the move I referred to templates using "APP/filename.html" string. Now I have to use "filename.html". I had to change all extends/includes template tags, and modify views. Somehow I expected that "APP" in "APP/filename.html" will hint to where to look for the file => in "djangoprojectroot/APP/templates/" directory. Anyway I like "filename.html" better because it is immune to application renaming. 2) All generic views were broken immediately, because by default they look for "APP/filename.html" templates. There are two ways to fix it: a) Place files like that: djangoprojectroot/APP/templates/APP/filename.html b) Use template_name parameter. I went with the latter, which clutters urls.py, but otherwise it is an acceptable solution, and it is immune to app renaming too. 3) It turned out that all template names should be unique. E.g., if I want to use "index.html", and there are two different files with this name in different applications, the template loader will use the first one according to the order of applications in INSTALLED_APPS. Checkmate. #3 renders the whole idea of keeping templates within application directories useless due to the risk of possible name clashes between applications. Switching to djangoprojectroot/APP/templates/APP/ is not immune to application renaming --- if you want to install your app with different name you have to change the name of the second APP subdirectory as well, and modify templates and views, or suffer a possible clash. But the problem is not about extra subdirectories. It is about keeping your template names unique. You can use "APP/filename.html" convention, or "APP_filename.html" convention, or anything else to make them unique (random numbers anyone?). It looks natural to separate templates into logical namespaces with some explicit mechanism of template overriding. There is a ticket #1586 (http://code.djangoproject.com/ticket/1586), which within one month was closed twice already. I understand it was confusing. It prevented one application to override templates for another application. Personally I find it confusing when some application overrides templates of 3rd-party applications: I should check all installed apps to see, if this is the case. And I should know all template names, which can be used by any given application. If that solution was unsatisfactory, probably we should find another one. Let me modify it a little bit. One possible way to fix #1586 is to require all overriding templates to be in the global "templates" directory. In this case the search path for "APP/filename.html" looks like that: 1) try djangoprojectroot/templates/APP/filename.html or other project-level locations --- use it to override templates 2) try djangoprojectroot/APP/templates/filename.html or other APP-specific locations (e.g., an .egg) 3) fail It makes template overriding explicit. You always know where to look --- just in two places really. It is super easy to implement. I understand that it is a compromise. It prevents having a self content application, which overrides another self-content application --- you have to do a project-level change (copy files to "templates" directory). I would love to hear better ideas! Thoughts? What additional problems should be addressed by the acceptable solution? Thanks, Eugene --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
