Re: BaseModelFormSet and ModelForm.instance
So I saw that #8160 has been pushed to post 1.0, which is understandable, but I've still been working on it since I need it fixed for a project. My previous patch was indeed failing all the model_formsets test, and it now passes all but one. The one test it fails on seems a bit odd to me though. It's testing the save_as_new argument to InlineFormSet and changes formset.instance after the formset has been constructed: >>> formset = AuthorBooksFormSet(data, instance=Author(), save_as_new=True) >>> formset.is_valid() True >>> new_author = Author.objects.create(name='Charles Baudelaire') >>> formset.instance = new_author >>> [book for book in formset.save() if book.author.pk == new_author.pk] The problem is that in my patch I set the formset's child forms instance attribute during _construct_forms(), which is called from BaseFormSet.__init__(), and that instance already has the fk set to formset.instance. Changing formset.instance after it's been initialized causes the formset and its child forms to have a mismatch. In the case of this test the child forms won't save because their author_id is None. I see two ways to solve this: 1) Consider BaseInlineFormSet to be private and change the test to save the Author instance before saving the formset, like this: >>> new_author = Author.objects.create(name='Charles Baudelaire') >>> formset = AuthorBooksFormSet(data, instance=new_author, save_as_new=True) >>> formset.is_valid() True >>> [book for book in formset.save() if book.author.pk == new_author.pk] 2) Reassign the fk values on all the child form instances during save. This isn't really that bad, but I don't think it really mirrors how multiple ModelForms would be used in the absence of FormSets, which has kind of been my guideline. I think it's analogous to changing ModelForm.instance after it's been initialized, which will cause problems because obj_data will be empty, so right now I'd go for option 1. There might be other issues with the patch too, especially since I remove some methods that I'm still not sure are part of the API or not, so I understand it probably won't make it into 1.0. I uploaded the new patch along with a separate patch to change the test it's failing. -Justin On Wed, Aug 20, 2008 at 12:36 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 20, 2008 at 11:42 AM, Justin Fagnani > <[EMAIL PROTECTED]> wrote: >> >> On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: >>> I am slightly unclear on what is allowed to >>> be broken in this phase of Django development. I suspect it is okay >>> since those methods are not explicitly documented and a quick note on >>> the wiki would be decent. Someone please correct me if I am wrong, but >>> will make this item post-1.0. >> >> I could rewrite the patch to preserve those methods, but it'd be a lot >> less elegant. I could see the argument that save_existing_objects(), >> and save_new_objects() are useful in some ways. > > One thing that I may have missed, but how are you dealing with > save_new in BaseInlineFormSet? From a quick glance that would seem > broken. > >> Yup, the tests pass. If I'm looking in the right places, the coverage >> seems pretty bad. ModelFormSets and InlineFormSets are not tested at >> all. > > Did you look at > http://code.djangoproject.com/browser/django/trunk/tests/modeltests/model_formsets/models.py? > >> >> Do you have a suggestion for not passing a queryset as the 'initial' >> argument to FormSet? I'm thinking that either the queryset is >> translated to a list of dicts like before, so the forms will have both >> an instance and initial data, or BaseFormSet.__init__() should be >> broken up so that _initial_form_count is set in another method that >> can be overridden. I like the later. > > I think the better solution here is to keep the __init__ code the same > but we need an instance level of the queryset persistent so we can use > the use the caching it would provide. Then use the the indexing like > you have with i local variable in _construct_form. > > -- > Brian Rosner > http://oebfare.com > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
discussion: can't iterate over lines in `UploadedFile` with `\r\n` or `\r` line endings
http://code.djangoproject.com/ticket/8149 As mentioned in the ticket, `UploadedFile.__iter__` iterates over a `StringIO` object to yield each line of the uploaded file (including line endings). Unfortunately the current version of `StringIO` only treats `\n` as a line ending, but iterating over a file object will yield lines regardless of the line ending type. I believe that future versions of `StringIO` work the same way as file objects do now. The problem with the current implementation is that we can't know what line ending uploaded text files will use, so anybody trying to iterate across lines of an uploaded file might get multiple lines or even the entire chunk or file in a single iteration. In order for users to reliably iterate through each line in an uploaded text file, they will need to write their own iterator to account for each possibility. A few possible workarounds for users that I can think of are: 1) Save the file to a temporary location on disk and open it as a file object, then iterate through that. This can be cumbersome because by default files under 2.5 MB are stored in memory, while larger files are already stored in a temporary location on disk. 2) Write a new iterator which includes the chunk/buffer logic of `UploadedFile.__iter__` but treats `\r\n` and `\r` as line endings as well as `\n`. 3) Load the entire file into memory and split it (if you don't need to retain the line endings). A few possible solutions on the django side could be: 1) Subclass `StringIO` and override `readline` to work with other line endings. This could be useful in other areas of Django, and could be considered similar to making the decimal module available to Python 2.3, by making future functionality of `StringIO` available now. 2) Rewrite `UploadedFile.__iter__` to not use `StringIO`. Some alternatives might be to parse the string in a similar way to `StringIO.readline`, or to use `re.findall` (with a gross pattern like the one found in the patch attached to the ticket), or to use `re.split` with a slightly less offensive pattern such as `re.split(r'(\r\n|\r|\n)', ...)` which would yield lines and line endings alternatively. Personally I think that it's not a rare edge case that users will want to accept text file uploads from unknown sources and that they should be able to iterate over each line of uploaded text files without re- writing that functionality in their own code. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: [PERFORM] select on 22 GB table causes "An I/O error occured while sending to the backend." exception
On Thu, Aug 28, 2008 at 7:53 PM, Matthew Dennis <[EMAIL PROTECTED]> wrote: > On Thu, Aug 28, 2008 at 8:11 PM, Scott Marlowe <[EMAIL PROTECTED]> > wrote: >> >> > wait a min here, postgres is supposed to be able to survive a complete >> > box >> > failure without corrupting the database, if killing a process can >> > corruptceived 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?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
I'm not quite sure how that relates to Composite Primary Keys? A ForeignKey would point to multiple internal fields, but it should look like it's a single field. At the same time, this would open up the possibility for Composite Foreign Keys, which would mean it could point to multiple public fields. On Thu, Aug 28, 2008 at 5:36 PM, Rock <[EMAIL PROTECTED]> wrote: > > To be clear, the syntax is: > > myfkey = models.ForeignKey(SomeClass,to_field="id") > > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django 1.0 and multithreading issues.
On Thu, 2008-08-28 at 16:42 -0700, Graham Dumpleton wrote: > Can someone give an update as to where Django 1.0 may stand in respect > of multithreading issues. > > I note that all the links to tickets referenced in: > > http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading > > seem to be crossed out, implying they are closed. > > Does this mean we are closer to being confident in saying Django may > be multithread safe or are there other issues that still need to be > addressed? Keep in mind that that page isn't neither a "specification" nor "core". It's a scratch pad of ideas by a few people (hard to tell how many because it's been edited anonymously at times). The naming is unfortunate and something we'll probably change in the near future. Definitely a useful page in some aspects, but to be treated appropriately as with anything in the wiki: anyone can, and has edited it, and it's difficult to view the history of what's gone on. At some point we'll have to rename it because people have been confused by the name. To answer your actual question, we should be pretty much threadsafe across the board. All tickets reported of that nature have been addressed. There are some places where we do intentional sharing, but they are just that: intentional. Other places should be filed as bugs, because they most likely are. To the best of my knowledge (and I do have some about the code), using multiple threads of execution for the same virtual host / location config blog (i.e. one settings file) should work. There are still things going on like os.environ being updated in the mod_python handler and Django having the general issue that it's going to be much harder to run multiple issues in one process space (than compared with your standard example of Trac) because people can and do import pretty much anything and they all populate the same memory space. That's why we don't currently have the multiple settings files for one virtual host type of setup: it's going to take a lot of documentation and care to make sure people have enough information to not blow their own feet off by importing contradictory sets of things. As a low level framework that is really just a small portion of any advanced usage, but which does do dynamic loading, that's a project for later (still a project, though, at least for me). Regards, Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Django 1.0 and multithreading issues.
On Thu, Aug 28, 2008 at 6:42 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > Can someone give an update as to where Django 1.0 may stand in respect > of multithreading issues. > > I note that all the links to tickets referenced in: > > http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading That's an interesting page I wasn't aware of. Who is mrts? :) --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Django 1.0 and multithreading issues.
Can someone give an update as to where Django 1.0 may stand in respect of multithreading issues. I note that all the links to tickets referenced in: http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading seem to be crossed out, implying they are closed. Does this mean we are closer to being confident in saying Django may be multithread safe or are there other issues that still need to be addressed? Graham --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
To be clear, the syntax is: myfkey = models.ForeignKey(SomeClass,to_field="id") --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: DjangoCon meetup Friday Sept 5
On Mon, Aug 25, 2008 at 8:38 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote: > > I tried to contact the TWID gusy through their website, but I haven't > heard back from them. Anyone know if they're still planning a get > together? Kevin Fricovsky (one of the co-founders of django-nyc) helps out with TWID, he should be able to find out for certain, but I haven't seen any mention. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Title of admin app index view is untranslatable
On Aug 28, 2008, at 17:24, Rudolph wrote: > Jacob marked it post-1.0 because of the "string freeze", but it > doesn't change or add any strings since the title was already marked > as translated. This patch just fixes a bug (actually it just moves one > bracket). I'd like propose to change back to milestone "1.0". Indeed, it does not change any translations at all. I definitely think it ought to be fixed, pre-1.0: It's a fix with no side-effects. Ludvig "toxik" Ericson --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: MultiDb status ?
What you are describing is an edge case for the notion of "sharding" which is the deployment of identically structured DBs where different batches of users get saved in different databases. (Flickr does this.) Sharding is a different problem than the more general notion of supporting multiple databases. It should be easier to accomplish, but that is just a guess as I am not up-to-speed on the Django internals with regards to connection management. I can imagine that a middleware-based solution might be possible. but it would require hacking at a level well below the standard APIs. I will give this some thought, but I have been focused on partitioning as the way to improve scalability and data management for large Django apps. On Aug 27, 3:40 am, Romain Gaches <[EMAIL PROTECTED]> wrote: > Hi, > > Thinking about switching from a homemade framework to django, I took a > look a the MultiDatabaseSupport stuff > (http://code.djangoproject.com/wiki/MultipleDatabaseSupport > ). > The related code seems to be 2 years old, is this branch still in > development ? > > I also noticed that the DB parameters are "statically" defined in the > settings. I'm actually looking for the ability to connect to a > database "on the fly" according to session-related data; would it be > possible without too much adapting work ? > > The aim is to have a separate database (with the same schema) for each > customer account in my app, the customer id being extracted from a > session variable. > > I'm currently using my own db manager: attaching & detaching databases > (SQLite, MySQL), cross-db requests, etc... but django's models are so > amazing I'd like to lighten my app with it :) > > -- > Romain --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
Ha! It turns out that a to_field option already exists for ForeignKey. (I did not know that yesterday.) I have just verified that to_field(SomeClass,"id") works fine even if the PRIMARY KEY uses multiple columns. However, and this is the key point, the id field has to be marked as UNIQUE. To prove all of this I have created a sqlresetpartition and resetpartition command that looks for classes to partition within your settings. It sets up the required multi-column primary key, marks the ID field as UNIQUE, and also does the other magic to create partitioned tables. (It also creates partitioned indexes as required.) This only works for Oracle and the solution is special cased for my needs, but it points the way forward. I will look over the partitioning logic for MySQL when I get a chance. Maybe by Django 1.5 or so we can include direct support for partitioned models. BTW, once I have the models properly created with partitions, none of my other django code requires any changes at all. Besides improved performance, I must say that it is a thrill to delete hundreds of thousands of old rows in less than a second. This is the key feature I needed for my django app. On Aug 27, 6:27 pm, Rock <[EMAIL PROTECTED]> wrote: > Well for one thing, if one of the columns happens to be named "ID", we > should use that for the relatedfields lookup column and that is that. > (BTW, does your approach allow the Django supplied ID field to be > combined with some other field(s) to make a multi-column key? This > would be bang up for future partitioning support.) > > Next I would suggest adding a meta model column designation like > "id_field" to specify a field to use for related classes. This might > be a good "80/20" solution that could serve for an initial test > version. > > On Aug 27, 5:27 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > > > > > Really I'm stuck at an architectural point. > > > I have database validation and synchronization done, and the admin is > > working. > > > What is left is more or less handling relatedfield lookups. The issue is, > > that field's are designed to reference more than one field, so it's a tough > > design deicision to make on how that should be approached.- Hide quoted > > text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Exceptions documention - #6842
On Aug 27, 9:34 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The precise location is probably in ref/ although perhaps jacob could > give a better answer. More importantly the way links are done has > been changed, check out > this:http://docs.djangoproject.com/en/dev/internals/documentation/ > for more info, also look at other docs for examples, or ask here or in > IRC. > > Thanks for your work I did see that the links changed format today when looking at another doc ticket. I will update that. Thanks for the feedback, John --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Updating a locale
Ok, Wil do that. Thanks On Aug 28, 5:01 pm, Rudolph <[EMAIL PROTECTED]> wrote: > Hi, > > The process is documented > here:http://www.djangoproject.com/documentation/contributing/#submitting-a... > > Doing it right now is a good time since strings are frozen until 1.0 > releases. > > Rudolph --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Updating a locale
Hi, The process is documented here: http://www.djangoproject.com/documentation/contributing/#submitting-and-maintaining-translations Doing it right now is a good time since strings are frozen until 1.0 releases. Rudolph --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Updating a locale
On Thu, Aug 28, 2008 at 4:29 AM, Tyler <[EMAIL PROTECTED]> wrote: > > Hi, > I want to update a locate(language) to include the new translations > submited. Great!. And the best thing is that this is documented so it makes things really straightforward, take a look at: http://docs.djangoproject.com/en/dev/topics/i18n/#id1 > What is the process to do such thing? > Just by doing a "django-admin.py makemessages ..." in the django root > tree? That would be: bin/django-admin.py makemessages -l bin/django-admin.py makemessages -l -d djangojs This will update all the translatable literals in django.po and djangojs.po so you can start updating these files with your translations. > Right now with the beta 2 the features will freeze, so the translation > strings too? No, string freeze means Django core developers aren't going to add new literals so you can concentrate in refining an hopefully translating all of them After that you can: Run bin/django-admin.py compilemessages -l to be sure there aren't syntax errors in the .po files Then open a ticket in Django Trac setting the component field to 'Translations' and attaching a patch containing your changes to the .po file. All this is described here: http://docs.djangoproject.com/en/dev/internals/contributing/#submitting-and-maintaining-translations Where you can also read about the django-i18n mailing list and how to handle things if you decide to do help or be in charge of one Django translation. > Is a good time now? Yes! your timing is perfect, but you have only a few days until 1.0 is released. Good luck. -- Ramiro Morales --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Title of admin app index view is untranslatable
Hi, I opened a ticket with a patch: http://code.djangoproject.com/ticket/8644 Jacob marked it post-1.0 because of the "string freeze", but it doesn't change or add any strings since the title was already marked as translated. This patch just fixes a bug (actually it just moves one bracket). I'd like propose to change back to milestone "1.0". BTW thanks for al the amazing work being done for 1.0 release! Rudolph --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: where are "core" and "models.TABULAR" ?
On Thu, Aug 28, 2008 at 5:51 AM, lowshoe <[EMAIL PROTECTED]> wrote: > what's happened with them? Short answer: we merged newforms-admin, which changes the way the admin models work. Consult the documentation. If you want a longer answer, the right place to ask is django-users; django-dev is used for discussion of developing Django itself, not usage questions. Jacob --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
500 error if django run in scgi mode(fcgi is ok)
Fcgi and scgi work well in my machine when i use django0.96.2, but scgi failed when I try to migrate my developing environment from django0.96.2 to svn version (rev 8643). I use the shell recommended by the fastcgi.txt to run fastcgi: exec /usr/bin/env - \ PYTHONPATH="../python:.." \ $PROJDIR//manage.py runfcgi protocol=$PROTOCOL socket=$SOCKET pidfile=$PIDFILE And i already chmod the .sock file for the permission issue. It's ok to navigate the web page if i set the PROTOCOL to "fcgi", but there will be 500 error when i change it to "scgi". The error messages in /var/log/lighttpd/error.log: 2008-08-28 13:57:42: (mod_fastcgi.c.3281) response not received, request sent: 920 on socket: unix:/home//workspace/.sock for /.fcgi , closing connection 2008-08-28 13:57:43: (mod_fastcgi.c.2471) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/home//workspace/.sock ... My machine enviroment: ubuntu: 8.02 en lighttpd: 1.4.9.19 MySql: 5.0.51a python: 2.5.2 flup:1.0 django: rev 8643 Are the some defects about sgci in current django or maybe i miss something? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
where are "core" and "models.TABULAR" ?
hi, i just made a fresh checkout of the trunk and now the parameters "edit_inline = models.TABULAR" and "core=True" in my model definitions throw the following errors: text = models.TextField(u'Text', core=True) TypeError: __init__() got an unexpected keyword argument 'core' answer = models.ForeignKey(QueryAnswer, verbose_name= u'Answer', null=True, blank=True, edit_inline = models.TABULAR) AttributeError: 'module' object has no attribute 'TABULAR' what's happened with them? regards, lowshoe --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Updating a locale
Hi, I want to update a locate(language) to include the new translations submited. What is the process to do such thing? Just by doing a "django-admin.py makemessages ..." in the django root tree? Right now with the beta 2 the features will freeze, so the translation strings too? Is a good time now? Thanks, Tyler --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
Jacob Kaplan-Moss schrieb: > On Tue, Aug 26, 2008 at 3:38 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > >> So it's a couple of days later...got time to update with your thoughts? >> > > Yeah, I'm sorry; I lost track of this. > > Essentially I think that James is right that a systematic fix would be > better, but I don't see what that might look like. > > Unfortunately, I'm really not sure exactly what we can do -- there's > some places where perhaps we could not raise ImproperlyConfigured, but > the problem is that sometimes those messages are *more* helpful, and > other times less. It's not entirely clear (to me) what a fix, even a > half-assed one, would look like > > > I started going down the path of having ImproperlyConfigured take an > ``original_exception`` argument and displaying that original exception > from manage.py, but that's pretty fiddly. I think catching any exception an raising ImporperlyConfigured is a good solution. But the original exception should not be lost. I wrote a patch several month ago. The original exception gets displayed in the debug view. manage.py is not handled: http://code.djangoproject.com/attachment/ticket/6537/6537.diff > So I think we need to do something along the lines of what's in > #7524... it's far, far from perfect, but it's probably the only way to > go to avoid a lot of frustration. > > Yes, I think this is a show stopper which should be solved before 1.0. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
500 error if django run in scgi mode(fcgi is ok)
Fcgi and scgi work well in my machine when i use django0.96.2, but scgi failed when I try to migrate my developing environment from django0.96.2 to svn version (rev 8643). I use the shell recommended by the fastcgi.txt to run fastcgi: exec /usr/bin/env - \ PYTHONPATH="../python:.." \ $PROJDIR//manage.py runfcgi protocol=$PROTOCOL socket= $SOCKET pidfile=$PIDFILE And i already chmod the .sock file for the permission issue. It's ok to navigate the web page if i set the PROTOCOL to "fcgi", but there will be 500 error when i change it to "scgi". The error messages in /var/log/lighttpd/error.log: 2008-08-28 13:57:42: (mod_fastcgi.c.3281) response not received, request sent: 920 on socket: unix:/home//workspace/.sock for / .fcgi , closing connection 2008-08-28 13:57:43: (mod_fastcgi.c.2471) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/home// workspace/.sock ... My machine enviroment: ubuntu: 8.02 en lighttpd: 1.4.9.19 MySql: 5.0.51a python: 2.5.2 flup:1.0 django: rev 8643 Are the some defects about scgi in current django or maybe i miss something? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
