date:20090109

Re: [Django] #10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()

2009-01-09 Thread Django

#10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()
---+
  Reporter:  jdo...@flinttechnology.co.uk  | Owner:  nobody 
 
Status:  new   | Milestone:  post-1.0   
 
 Component:  Forms |   Version: 
 
Resolution:|  Keywords:  
modelform_factory assumption
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Jon):

 Amendment - code to reproduce exception:
 {{{
 class ImportAdminAddForm(forms.ModelForm):

 class Meta:
 model = Import

 class ImportAdminForm(forms.ModelForm):

 class Meta:
 model = Import

 def __init__(self, *args, **kwargs):
 super(ImportAdminForm, self).__init__(self, *args, **kwargs)
 ### Causes Exception

 class ImportAdminAdd(admin.ModelAdmin):

 form = ImportAdminAddForm

 class ImportAdmin(admin.ModelAdmin):

 form = ImportAdminForm

 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()

2009-01-09 Thread Django

#10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()
---+
  Reporter:  jdo...@flinttechnology.co.uk  | Owner:  nobody 
 
Status:  new   | Milestone:  post-1.0   
 
 Component:  Forms |   Version: 
 
Resolution:|  Keywords:  
modelform_factory assumption
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Jon):

 Please hide/remove submitters email address - would appreciate update but
 not bot spam. Thanks.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()

2009-01-09 Thread Django

#10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()
+---
   Reporter:  jdo...@flinttechnology.co.uk  |Owner:  nobody
 Status:  new   |Milestone:  post-1.0  
  Component:  Forms |  Version:
   Keywords:  modelform_factory assumption  |Stage:  Unreviewed
  Has_patch:  0 |   Needs_docs:  0 
Needs_tests:  0 |   Needs_better_patch:  0 
+---
 {{{
 debug dump:
   c:\python26\lib\site-
 packages\django\core\management\commands\runserver.py(61)inner_run
 -> run(addr, int(port), handler)
   c:\python26\lib\site-packages\django\core\servers\basehttp.py(676)run()
 -> httpd.serve_forever()
   c:\python26\lib\socketserver.py(226)serve_forever()
 -> self._handle_request_noblock()
   c:\python26\lib\socketserver.py(281)_handle_request_noblock()
 -> self.process_request(request, client_address)
   c:\python26\lib\socketserver.py(307)process_request()
 -> self.finish_request(request, client_address)
   c:\python26\lib\socketserver.py(320)finish_request()
 -> self.RequestHandlerClass(request, client_address, self)
   c:\python26\lib\site-
 packages\django\core\servers\basehttp.py(558)__init__()
 -> BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
   c:\python26\lib\socketserver.py(615)__init__()
 -> self.handle()
   c:\python26\lib\site-
 packages\django\core\servers\basehttp.py(603)handle()
 -> handler.run(self.server.get_app())
   c:\python26\lib\site-packages\django\core\servers\basehttp.py(278)run()
 -> self.result = application(self.environ, self.start_response)
   c:\python26\lib\site-
 packages\django\core\servers\basehttp.py(635)__call__()
 -> return self.application(environ, start_response)
   c:\python26\lib\site-
 packages\django\core\handlers\wsgi.py(239)__call__()
 -> response = self.get_response(request)
   c:\python26\lib\site-
 packages\django\core\handlers\base.py(86)get_response()
 -> response = callback(request, *callback_args, **callback_kwargs)
   c:\python26\lib\site-packages\django\contrib\admin\sites.py(157)root()
 -> return self.model_page(request, *url.split('/', 2))
   c:\python26\lib\site-
 packages\django\views\decorators\cache.py(44)_wrapped_view_func()
 -> response = view_func(request, *args, **kwargs)
   c:\python26\lib\site-
 packages\django\contrib\admin\sites.py(176)model_page()
 -> return admin_obj(request, rest_of_url)
   c:\python26\lib\site-
 packages\django\contrib\admin\options.py(198)__call__()
 -> return self.change_view(request, unquote(url))
   c:\python26\lib\site-
 packages\django\db\transaction.py(238)_commit_on_success()
 -> res = func(*args, **kw)
   c:\python26\lib\site-
 packages\django\contrib\admin\options.py(566)change_view()
 -> ModelForm = self.get_form(request, obj)
   c:\python26\lib\site-
 packages\django\contrib\admin\options.py(278)get_form()
 -> return modelform_factory(self.model, **defaults)
 > c:\python26\lib\site-
 packages\django\forms\models.py(334)modelform_factory()
 -> return ModelFormMetaclass(class_name, (form,), {'Meta': Meta,
 (Pdb) l 328
 323
 324 def modelform_factory(model, form=ModelForm, fields=None,
 exclude=None,
 325formfield_callback=lambda f:
 f.formfield()):
 326 # HACK: we should be able to construct a ModelForm without
 creating
 327 # and passing in a temporary inner class
 328 class Meta:
 329 pass
 330 setattr(Meta, 'model', model)
 331 setattr(Meta, 'fields', fields)
 332 setattr(Meta, 'exclude', exclude)
 333 class_name = model.__name__ + 'Form'
 (Pdb) l
 334  -> return ModelFormMetaclass(class_name, (form,), {'Meta': Meta,
 335   'formfield_callback':
 formfield_callback})
 336
 337
 338 # ModelFormSets
 ##
 339
 340 class BaseModelFormSet(BaseFormSet):
 341 """
 342 A ``FormSet`` for editing a queryset and/or adding new objects
 to it.
 343 """
 344 model = None
 (Pdb) p model
 
 (Pdb) p form
 
 (Pdb) p class_name
 'ImportForm'
 [* INCORRECT ***]
 }}}

 yields exception:

 {{{
 165 def value_from_datadict(self, data, files, name):
 166 """
 (Pdb)
 167 Given a dictionary of data and this widget's name, returns
 the value
 168 of this widget. Returns None if it's not provided.
 169 """
 170 import pdb; pdb.set_trace()
 171  -> return data.get(name, None)
 172
 173 def _has_changed(self, initial, data):
 174 """
 175 Return True if data differs from initial.
 176 """
 177 #

Re: [Django] #8138: Switch django tests to use transactions

2009-01-09 Thread Django

#8138: Switch django tests to use transactions
+---
  Reporter:  mremolt| Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 OK, with Ramiro's pointers as a guide, I've figured out what, exactly,
 causes the time zone mismatch reported by modeltests/fixtures with the
 current patch.  (Attributing it to the rollback usage didn't quite answer
 the question for me completely since I couldn't see why just the time zone
 setting and not the actual data addition was being rolled back using the
 new approach.)  What's happening is the result of bracketing the doctest
 run by the transaction stuff:

 {{{
 #!python
 def run(self, test, compileflags=None, out=None, clear_globs=True):
 """
 Wraps the parent run() and encloses it in a transaction.
 """
 transaction.enter_transaction_management()
 transaction.managed(True)
 result = doctest.DocTestRunner.run(self, test, compileflags, out,
 clear_globs)
 transaction.rollback()
 transaction.leave_transaction_management()
 return result
 }}}

 The sequence of tests that is failing is first:

 {{{
 #!python
 # Load fixture 1 again, using format discovery
 >>> management.call_command('loaddata', 'fixture1', verbosity=0)
 }}}

 That loaddata uses a connection that has had its timezone set to whatever
 is in settings.  The loaddata works, the data is committed to the DB, and
 that connection is closed by this code at the very end of loaddata.py:

 {{{
 #!python
 # Close the DB connection. This is required as a workaround for an
 # edge case in MySQL: if the same connection is used to
 # create tables, load data, and query, the query can return
 # incorrect results. See Django #7572, MySQL #37735.
 if commit:
 connection.close()
 }}}

 Next thing in the test is this:

 {{{
 #!python
 >>> Article.objects.all()
 [, , ]
 }}}

 which opens a new connection, sets the timezone, and retrieves these
 results from the DB.  No commit yet, so the timezone setting is vulnerable
 to rollback.

 Next in the test is:

 {{{
 #!python
 # Try to load fixture 2 using format discovery; this will fail
 # because there are two fixture2's in the fixtures directory
 >>> management.call_command('loaddata', 'fixture2', verbosity=0) #
 doctest: +ELLIPSIS
 Multiple fixtures named 'fixture2' in '...fixtures'. Aborting.
 }}}

 This loaddata is going to fail, and it is what causes the timezone setting
 to be rolled back, since loaddata calls rollback in the case of failure.
 The dumpdata is then called subsequently on the same connection, where the
 timezone has reverted to whatever matches the actual OS timezone.  If this
 is different from what is in settings (or the default of America/Chicago
 if settings is silent on the matter of timezone) then the times in the
 dumpdata results will be off.

 But still it wasn't clear why this rollback by loaddata was only a problem
 with the patch code.  The answer to that is this code near the beginning
 of loaddata:

 {{{
 #!python
 # Start transaction management. All fixtures are installed in a
 # single transaction to ensure that all references are resolved.
 if commit:
 transaction.commit_unless_managed()
 transaction.enter_transaction_management()
 transaction.managed(True)
 }}}

 So on entry to loaddata, the uncommitted set timezone will be committed
 before the failure-induced rollback if the doctest itself has not been
 bracketed by the `enter_transaction_management`, etc.

 Not sure what the right fix is.  A brief experiment with sqlite seems to
 indicate that the patch's changes to bracket `DocTestRunner.run` in a
 transaction that is rolled back are not actually necessary for
 successfully running the Django test suite.  That is I can remove that
 whole `run` override and all Django tests pass.  (This is also consistent
 with not seeing any problems caused by this newly added rollback not
 working on MySQL/MyISAM.)  So apparently anything done to the DB by
 doctests don't interfere with subsequent tests in the Django testsuite.
 But I'm a bit out of my depth here in knowing if that would be an OK
 approach -- it seems inconsistent for one type of test to use rolled-back
 transactions and the other to not.

 Alternatively, always immediately committing the timezone setting seems
 harmless, since it is only done when a new connection

Re: [Django] #7270: selected_related() can not follow reverse relations of OneToOne.

2009-01-09 Thread Django

#7270: selected_related() can not follow reverse relations of OneToOne.
---+
  Reporter:  towjz...@hotmail.com  | Owner:  gav

Status:  new   | Milestone:  post-1.0   

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  
select_related onetoone reverse
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by andrewbadr):

 * cc: andrewbadr@gmail.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7210: Added expression support for QuerySet.update

2009-01-09 Thread Django

#7210: Added expression support for QuerySet.update
---+
  Reporter:  sebastian_noack   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  1 
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: si...@akoha.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10004: Enable -c switch in xgettext call to collect translator comments

2009-01-09 Thread Django

#10004: Enable -c switch in xgettext call to collect translator comments
---+
  Reporter:  claudep   | Owner:  
Status:  new   | Milestone:  
 Component:  Internationalization  |   Version:  1.0 
Resolution:|  Keywords:  makemessages
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  mtredinnick =>
  * status:  assigned => new

Comment:

 Whoops. Didn't mean to assign this to me. Anybody can do this with care
 and research.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10004: Enable -c switch in xgettext call to collect translator comments

2009-01-09 Thread Django

#10004: Enable -c switch in xgettext call to collect translator comments
---+
  Reporter:  claudep   | Owner:  mtredinnick 
Status:  assigned  | Milestone:  
 Component:  Internationalization  |   Version:  1.0 
Resolution:|  Keywords:  makemessages
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * component:  django-admin.py => Internationalization
  * needs_tests:  => 0
  * owner:  nobody => mtredinnick
  * needs_docs:  => 0

Comment:

 I thought there was already a ticket open for this, but I can't find it
 now. So maybe it's just one of those things that's been on my TODO list
 for ages. We should certainly do something like this. We need to specify
 (and document) a tag to mark the comments to include, since there are lots
 of places where there are comments preceding translation calls that are
 not at all relevant to the localisation process.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9999: Documentation for testing

2009-01-09 Thread Django

#: Documentation for testing
+---
  Reporter:  ericholscher   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Dupe of #9962.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9994: list_filter ignores to_field

2009-01-09 Thread Django

#9994: list_filter ignores to_field
---+
  Reporter:  jzylks| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * status:  new => assigned

Comment:

 This isn't a complete fix, since if the related field points to another
 model (chained foreign keys) and so on, I suspect it ends up returning an
 object and not a pk value. This problem exists in a few places were we're
 trying to retrieve the "pk value" (really meaning the representative value
 for the related column) and I keep meaning to fix it holistically in the
 model class.

 Assigning to me so that I have a bug to track that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3460: Allow configuration of postgresql_psycopg2 isolation level

2009-01-09 Thread Django

#3460: Allow configuration of postgresql_psycopg2 isolation level
+---
  Reporter:  Jack Moffitt   | Owner:  
Richard Davies 
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:  SVN   
  
Resolution: |  Keywords:
  
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  1  |   Needs_tests:  0 
  
Needs_better_patch:  1  |  
+---
Changes (by mtredinnick):

  * needs_docs:  0 => 1

Comment:

 You didn't read my comment. Anything that changes the default isolation
 level isn't going to be accepted. That will lead to very hard to diagnose
 bugs in some existing code that is relying on the current isolation level.
 However, a patch that allows configuration of the isolation level to use
 is certainly a good idea and will be accepted. But the default remains as
 it is. I have no problems understanding that the current level causes
 problems for some use-cases. Which is fine. But they aren't the only use-
 cases and considering existing (two separate items) are also very
 important. This has been discussed ad-infinitum on the django-dev mailing
 list.

 Since it sounds like the current patch is another case of changing the
 default, it needs improvement. Add a setting for the isolation level. The
 default value is the current level. Add some documentation for how to
 change it. Then we've got something that can be committed. Get it done
 reasonably quickly (within about a week) and this can make it into Django
 1.1.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9438: Integrate django-testmaker functionality into Django

2009-01-09 Thread Django

#9438: Integrate django-testmaker functionality into Django
+---
  Reporter:  ericholscher   | Owner:  ericholscher
Status:  closed | Milestone:  
 Component:  Testing framework  |   Version:  1.0 
Resolution:  wontfix|  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by ericholscher):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 This was rejected for 1.1. I will maintain it externally for now.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10004: Enable -c switch in xgettext call to collect translator comments

2009-01-09 Thread Django

#10004: Enable -c switch in xgettext call to collect translator comments
-+--
 Reporter:  claudep  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django-admin.py  | Version:  1.0   
 Keywords:  makemessages |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 gettext infrastructure provides for translator comments in source code
 (just on the line before the string to translate) to be copied into po
 files. However, this required the -c (--add-comment) option to be passed
 to xgettext. Please add this in makemessages.py ("xgettext -c -d ...").

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10003: if and extends in template

2009-01-09 Thread Django

#10003: if and extends in template
--+-
  Reporter:  0ptr | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Template system  |   Version:  1.0   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by 0ptr):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Ok actually better way is to return the template name from context
 processor and extend it directly

 {% extends ua_based_template %}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10003: if and extends in template

2009-01-09 Thread Django

#10003: if and extends in template
-+--
 Reporter:  0ptr |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 {{{

 {% if mobile %}
 {% extends 'base_mobile.html' %}
 {% else %}
 {% extends 'base_normal.html' %}
 {% endif %}


 }}}

 Throws following exception:


 {{{
 Exception Type: TemplateSyntaxError
 Exception Value:
 Invalid block tag: 'else'
 Exception Location: /home/dsduser/django-
 synble/django/template/__init__.py in invalid_block_tag, line 333
 }}}

 I think this should be supported. Second option is to write include
 correctly so that include does not broke inheritance. E.g.:

 basbase.html: has block

 base.html: include "basebase.html"

 logic.html: extends "base.html", inheritance of basbase.html block does
 not work here anymore.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10002: Data does not display in TabularInline when validation fails for an ImageField

2009-01-09 Thread Django

#10002: Data does not display in TabularInline when validation fails for an
ImageField
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:  post-1.0  
Component:  django.contrib.admin   | Version:  1.0   
 Keywords:  TabularInline, ImageField  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I have a TabularInline form associated with a model in my admin and it has
 an ImageField and a CharField.  When I edit / add a record to the list and
 do not upload an image, Click save and edit, it throws an error "This
 field is required" and wipes out all of the previous data (the data is not
 lost, it just doesn't appear in the list).

 ---model:

 {{{
 class Example(models.Model):
 name = models.CharField(max_length=128)
 test = models.ForeignKey(Test, related_name="examples")
 image = models.ImageField(upload_to=settings.UPLOAD_TO)

 }}}

 ---admin:

 {{{
 class ExampleInline(admin.TabularInline):
 model = Example

 class TestAdmin(admin.ModelAdmin):
 inlines = [ExampleInline,]

 admin.site.register(Test, TestAdmin)

 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6271: filter arguments with spaces break several template tags

2009-01-09 Thread Django

#6271: filter arguments with spaces break several template tags
--+-
  Reporter:  Rob Hudson   | Owner:  
   
Status:  new  | Milestone:  
   
 Component:  Template system  |   Version:  SVN 
   
Resolution:   |  Keywords:  
tplrf-fixed
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  1|  
--+-
Comment (by dc):

 #10001 has been marked as a duplicate of this ticket. It also contains
 small patch for smart_split().

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10001: smart_split should be more versatile

2009-01-09 Thread Django

#10001: smart_split should be more versatile
-+--
  Reporter:  zpao| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by dc):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Duplicate of #6271

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6845: Model validation and its propagation to ModelForms

2009-01-09 Thread Django

#6845: Model validation and its propagation to ModelForms
-+--
  Reporter:  Honza_Kral  | Owner:  Honza_Kral   
 
Status:  new | Milestone:  post-1.0 
 
 Component:  Forms   |   Version:  SVN  
 
Resolution:  |  Keywords:  newforms validation model 
modelform ep2008
 Stage:  Accepted| Has_patch:  1
 
Needs_docs:  1   |   Needs_tests:  1
 
Needs_better_patch:  1   |  
-+--
Comment (by mrts):

 Interested parties should follow http://wiki.github.com/HonzaKral/django
 /model-validation

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10001: smart_split should be more versatile

2009-01-09 Thread Django

#10001: smart_split should be more versatile
+---
 Reporter:  zpao|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 smart_split should accept input such that the following is true:

 {{{
 >>> list(smart_split(r"A variable='value' should work."))
 [u'A', u"variable='value'" u'should' u'work']
 >>> list(smart_split(r"A variable='value with spaces' should also work."))
 [u'A', u"variable='value with spaces'", u'should', u'also', u'work.']
 }}}

 With this, multiple word strings can be passed to variables in a template.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
-+--
  Reporter:  ubernostrum | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * status:  reopened => closed
  * resolution:  => fixed

Comment:

 Please do not anonymously reopen tickets closed by a commiter.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
-+--
  Reporter:  ubernostrum | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * status:  closed => reopened
  * resolution:  fixed =>

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
-+--
  Reporter:  ubernostrum | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by adrian):

 These sorts of fun and games would have been valid had somebody not closed
 my own ticket #1000. I will never forgive that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9998: Document side effects of importing uninstalled models

2009-01-09 Thread Django

#9998: Document side effects of importing uninstalled models
+---
  Reporter:  ubernostrum| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by brosner):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
-+--
  Reporter:  ubernostrum | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Now there's one fewer.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
-+--
  Reporter:  ubernostrum | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by ericholscher):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 +1

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10000: Django has too many open tickets

2009-01-09 Thread Django

#1: Django has too many open tickets
+---
 Reporter:  ubernostrum |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Nearly 1400 at the moment. We should have some sprints and fix a bunch of
 'em.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9999: Documentation for testing

2009-01-09 Thread Django

#: Documentation for testing
---+
 Reporter:  ericholscher   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The documentation for django needs more examples for testing. This will
 have a patch for adding testing docs, and hopefully for adding testing as
 part 5 for the tutorial.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9998: Document side effects of importing uninstalled models

2009-01-09 Thread Django

#9998: Document side effects of importing uninstalled models
---+
 Reporter:  ubernostrum|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If a model is in an application not listed in `INSTALLED_APPS`, but is
 imported by some piece of code that's nonetheless in use, weird behavior
 can ensue (up to and including other models receiving reverse relations
 and thus erroring on delete operations when they try to select or delete
 from a non-existent related table).

 This should be documented a bit more clearly, to ensure people don't trip
 over it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9997: Nested queries support: Field for ValuesListQuerySet (flat=True) gets lost in query construction

2009-01-09 Thread Django

#9997: Nested queries support: Field for ValuesListQuerySet (flat=True) gets 
lost
in query construction
---+
  Reporter:  mk| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mk):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9997: Nested queries support: Field for ValuesListQuerySet (flat=True) gets lost in query construction

2009-01-09 Thread Django

#9997: Nested queries support: Field for ValuesListQuerySet (flat=True) gets 
lost
in query construction
---+
 Reporter:  mk |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I have a model called Favorite which has a generic foreign key. I want to
 get all bookmarked jobs for a user efficiently, therefore I query the
 database for all object_ids:

 {{{
 ids =
 
Favorite.objects.get_favorites_by_model(Job).filter(user=1).values_list('object_id',
 flat=True)

 In [28]: ids
 Out[28]: [338L, 308L, 212L, 345L, 307L, 264L, 322L, 354L, 326L, 328L,
 335L, 334L, 332L, 353L, 352L, 351L, 350L, 349L, 316L]

 In [33]: type(ids)
 Out[33]: 
 }}}

 Now, using this information I want to get a list of all jobs. However, the
 following two statements yield completely different results. Only the
 former is correct:

 {{{
 In [22]: Job.objects.filter(id__in=tuple(ids))
 Out[22]: [http://code.djangoproject.com/ticket/9997>
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9996: Missing angled bracket on tag in a contrib.comments template

2009-01-09 Thread Django

#9996: Missing angled bracket on  tag in a contrib.comments template
---+
  Reporter:  daveyjoe  | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Contrib apps  |   Version:  1.0
  
Resolution:  invalid   |  Keywords:  comments, contrib, html, 
template
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by daveyjoe):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Sorry, my mistake. I didn't read the file properly, the closing angled
 bracket is on line 9 (a couple of p attributes are specified first).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9996: Missing angled bracket on tag in a contrib.comments template

2009-01-09 Thread Django

#9996: Missing angled bracket on  tag in a contrib.comments template
---+
 Reporter:  daveyjoe   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Contrib apps   | Version:  1.0   
 Keywords:  comments, contrib, html, template  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I was taking a look through the source code and I noticed that there is a
 missing angled bracket on a  tag.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9994: list_filter ignores to_field

2009-01-09 Thread Django

#9994: list_filter ignores to_field
---+
  Reporter:  jzylks| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jzylks):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I've found a possible fix for this:

 filterspecs.py, Line 61

 Changing

 {{{self.lookup_kwarg = '%s__%s__exact' % (f.name,
 f.rel.to._meta.pk.name)}}}

 to

 {{{self.lookup_kwarg = '%s__%s__exact' % (f.name,
 f.rel.get_related_field().attname)}}}

 fixes the problem for me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9995: Mention 'easy_install Django' as an alternative installation method.

2009-01-09 Thread Django

#9995: Mention 'easy_install Django' as an alternative installation method.
+---
  Reporter:  daveyjoe   | Owner:  nobody
 
Status:  new| Milestone:
 
 Component:  Documentation  |   Version:  1.0   
 
Resolution: |  Keywords:  easy_install, docs, 
documentation, install, installation, setup
 Stage:  Unreviewed | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by daveyjoe):

  * needs_better_patch:  => 0
  * summary:  Mention 'easy_install Django' as an alternative method
  installation method. => Mention 'easy_install
  Django' as an alternative installation method.
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9995: Mention 'easy_install Django' as an alternative method installation method.

2009-01-09 Thread Django

#9995: Mention 'easy_install Django' as an alternative method installation 
method.
-+
 Reporter:  daveyjoe |  
 Owner:  nobody
   Status:  new  |  
 Milestone:
Component:  Documentation|  
   Version:  1.0   
 Keywords:  easy_install, docs, documentation, install, installation, setup  |  
 Stage:  Unreviewed
Has_patch:  1|  
-+
 Now that there are no issues with ``easy_install Django``, I think that it
 should be mentioned as an alternative method of install on the docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9994: list_filter ignores to_field

2009-01-09 Thread Django

#9994: list_filter ignores to_field
--+-
 Reporter:  jzylks|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 When using the to_field option in a foreign key field, and then filtering
 on that field in the admin interface, the filter attempts to match the
 primary key with the values taken from the to_field.

 For Example:

 {{{

 class Department(models.Model):
 code = models.CharField(max_length=4, unique=True)
 description = models.CharField(max_length=50, blank=True,
 null=True)

 class Employee(models.Model):
 department = models.ForeignKey(Department, to_field="code")
 name = models.CharField(max_length=100)

 ...

 class EmployeeAdmin(admin.ModelAdmin):
 list_display = ['name', 'department']
 list_filter = ['department']

 ...

 }}}

 Suppose there is a department, 'FINC' with id 1; the filter that is
 generated is {{{department__id__exact=FINC}}} rather than
 {{{department__code__exact=FINC}}} or {{{department__id__exact=1}}}.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3460: Allow configuration of postgresql_psycopg2 isolation level

2009-01-09 Thread Django

#3460: Allow configuration of postgresql_psycopg2 isolation level
+---
  Reporter:  Jack Moffitt   | Owner:  
Richard Davies 
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:  SVN   
  
Resolution: |  Keywords:
  
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  1  |  
+---
Comment (by iamseb):

 As stated in the original ticket, django does not use an appropriate
 isolation level by default. This is a serious bug for anyone deploying
 django with postgres, a bug that has cost us considerable time and effort
 (and therefore, money). The patches submitted are intended to offer a
 simple, working fix that solves this issue, and hopefully to promote
 further discussion so that we can get a complete solution in django.

 {{{
 "Django should be using the autocommit isolation level, which does not
 have this overhead. Anywhere explicit transaction blocks are needed they
 can be used."
 }}}

 The penultimate ticket resolves this issue by ensuring that the correct
 isolation level is set by the psycopg2 backend for *all* transactions. We
 believe that this is the correct, expected behaviour. The final patch
 resolves a side-effect of this change by changing the lookup of newly
 inserted primary keys to a pattern that is held within a single
 transaction.

 Sorry if this wasn't clearer.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3460: Allow configuration of postgresql_psycopg2 isolation level

2009-01-09 Thread Django

#3460: Allow configuration of postgresql_psycopg2 isolation level
+---
  Reporter:  Jack Moffitt   | Owner:  
Richard Davies 
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:  SVN   
  
Resolution: |  Keywords:
  
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  1  |  
+---
Changes (by mtredinnick):

  * summary:  postgresql_psycopg2 backend uses wrong isolation level =>
  Allow configuration of postgresql_psycopg2
  isolation level
  * stage:  Design decision needed => Accepted

Comment:

 This ticket seems to be devolving into multiple issues, which is bad. The
 title of the ticket is a bit incorrect at the moment (and I'm about to
 change that).

 Right now, Django isn't using the "incorrect" isolation level. It's using
 one of the valid options. There's a proposal, which has been accepted, to
 introduce a configurable option to allow a different isolation level to be
 used, as per the original poster's request. That is what this ticket is
 about. However, the current level is what will remain as the default;
 changing that introduces undetectable and potentially unsafe side-effects
 into existing code.

 If there are issues with counters being in separate transactions and
 things like that, they should really be in a separate ticket, since they
 must also be fixed with the current code. It looks to me like the last two
 patches (the penultimate patch needs a better explanation of the problem
 it is trying to solve, too. It's a little hard to reverse engineer and I'd
 like to have more confidence that my interpretation matches the patch
 authors') really both belong in a separate ticket, since they aren't
 dealing with the serialisation level at all. So if iamseb or nicferrier
 could please fix that, including a description of the problem you're
 trying to fix, it would be appreciated.

 (Changed description to reflect the targeted solution)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3460: postgresql_psycopg2 backend uses wrong isolation level

2009-01-09 Thread Django

#3460: postgresql_psycopg2 backend uses wrong isolation level
+---
  Reporter:  Jack Moffitt   | Owner:  
Richard Davies 
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:  SVN   
  
Resolution: |  Keywords:
  
 Stage:  Design decision needed | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  1  |  
+---
Comment (by iamseb):

 Following up from nicferrier's patch, there's a corresponding issue when
 using transaction pooling which must be resolved.

 INSERT statements followed by SELECT CURRVAL for creating new objects may
 split the queries over two transactions, and therefore two sessions. The
 second session will not have the sequence value available. In this case, a
 far safer route is to use the RETURNING clause in INSERT statements to
 return the new value for the pk.

 The attached insertwithreturning.patch adds a new feature to
 BaseDatabaseFeatures, sets it to true for the psycopg2 backend, and
 conditionally creates an appropriate RETURNING clause for INSERT
 statements.

 This feature is supported for PostgreSQL 8+ with psycopg2 (tested), and
 Oracle (untested, currently not enabled).

 With these two patches, correct transaction isolation support for postgres
 is fully implemented, and scaling issues with lock concurrency and hanging
 transactions are mitigated. (We've seen >10k locks reduced to <100.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9726 - in django/branches/releases/1.0.X: django/views docs/howto

2009-01-09 Thread noreply


Author: mtredinnick
Date: 2009-01-09 06:42:35 -0600 (Fri, 09 Jan 2009)
New Revision: 9726

Modified:
   django/branches/releases/1.0.X/django/views/static.py
   django/branches/releases/1.0.X/docs/howto/static-files.txt
Log:
[1.0.X] Revised r9567 slightly to be backwards compatible with versions 1.0 - 
1.0.2.

Also documented the change. We prefer to load directory_index.html for static
directory listings, but if you have the (older style) "directory_index"
template and no .html version, we'll load that. This should stop a bunch of
mysterious breakages when people upgrade to Django 1.0.3 or Django 1.1. Also
keeps the docs in sync with released code.

Fixed #9993.

Backport of r9725 from trunk.

Modified: django/branches/releases/1.0.X/django/views/static.py
===
--- django/branches/releases/1.0.X/django/views/static.py   2009-01-09 
12:41:07 UTC (rev 9725)
+++ django/branches/releases/1.0.X/django/views/static.py   2009-01-09 
12:42:35 UTC (rev 9726)
@@ -91,7 +91,8 @@
 
 def directory_index(path, fullpath):
 try:
-t = loader.get_template('static/directory_index.html')
+t = loader.select_template(['static/directory_index.html',
+'static/directory_index'])
 except TemplateDoesNotExist:
 t = Template(DEFAULT_DIRECTORY_INDEX_TEMPLATE, name='Default directory 
index template')
 files = []

Modified: django/branches/releases/1.0.X/docs/howto/static-files.txt
===
--- django/branches/releases/1.0.X/docs/howto/static-files.txt  2009-01-09 
12:41:07 UTC (rev 9725)
+++ django/branches/releases/1.0.X/docs/howto/static-files.txt  2009-01-09 
12:42:35 UTC (rev 9726)
@@ -90,7 +90,7 @@
 * ``directory`` -- the directory name (a string)
 * ``file_list`` -- a list of file names (as strings) in the directory
 
-Here's the default ``static/directory_index`` template:
+Here's the default ``static/directory_index.html`` template:
 
 .. code-block:: html+django
 
@@ -112,6 +112,14 @@
 
 
 
+.. versionchanged:: 1.0.3
+Prior to Django 1.0.3, there was a bug in the view that provided directory
+listings. The template that was loaded had to be called
+``static/directory_listing`` (with no ``.html`` extension). For backwards
+compatibility with earlier versions, Django will still load templates with
+the older (no extension) name, but it will prefer a the
+``directory_index.html`` version.
+
 Limiting use to DEBUG=True
 ==
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9725 - in django/trunk: django/views docs/howto

2009-01-09 Thread noreply


Author: mtredinnick
Date: 2009-01-09 06:41:07 -0600 (Fri, 09 Jan 2009)
New Revision: 9725

Modified:
   django/trunk/django/views/static.py
   django/trunk/docs/howto/static-files.txt
Log:
Revised r9566 slightly to be backwards compatible with versions 1.0 - 1.0.2.

Also documented the change. We prefer to load directory_index.html for static
directory listings, but if you have the (older style) "directory_index"
template and no .html version, we'll load that. This should stop a bunch of
mysterious breakages when people upgrade to Django 1.0.3 or Django 1.1. Also
keeps the docs in sync with released code.

Fixed #9993.

Modified: django/trunk/django/views/static.py
===
--- django/trunk/django/views/static.py 2009-01-09 09:57:53 UTC (rev 9724)
+++ django/trunk/django/views/static.py 2009-01-09 12:41:07 UTC (rev 9725)
@@ -91,7 +91,8 @@
 
 def directory_index(path, fullpath):
 try:
-t = loader.get_template('static/directory_index.html')
+t = loader.select_template(['static/directory_index.html',
+'static/directory_index'])
 except TemplateDoesNotExist:
 t = Template(DEFAULT_DIRECTORY_INDEX_TEMPLATE, name='Default directory 
index template')
 files = []

Modified: django/trunk/docs/howto/static-files.txt
===
--- django/trunk/docs/howto/static-files.txt2009-01-09 09:57:53 UTC (rev 
9724)
+++ django/trunk/docs/howto/static-files.txt2009-01-09 12:41:07 UTC (rev 
9725)
@@ -90,7 +90,7 @@
 * ``directory`` -- the directory name (a string)
 * ``file_list`` -- a list of file names (as strings) in the directory
 
-Here's the default ``static/directory_index`` template:
+Here's the default ``static/directory_index.html`` template:
 
 .. code-block:: html+django
 
@@ -112,6 +112,14 @@
 
 
 
+.. versionchanged:: 1.0.3
+Prior to Django 1.0.3, there was a bug in the view that provided directory
+listings. The template that was loaded had to be called
+``static/directory_listing`` (with no ``.html`` extension). For backwards
+compatibility with earlier versions, Django will still load templates with
+the older (no extension) name, but it will prefer a the
+``directory_index.html`` version.
+
 Limiting use to DEBUG=True
 ==
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9993: "directory_index.html" does not work

2009-01-09 Thread Django

#9993: "directory_index.html" does not work
+---
  Reporter:  Gurur  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by mtredinnick):

 This was actually a bug in the code (it used to automatically append the
 .html, but that was changed a while back and the static loader wasn't
 updated). We have fixed it in the code base now (see ticket #9754 and
 commits r9566 and r9567). The fix will be in Django 1.0.3.

 I'll add a note to the documentation to reflect the bug, however.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9993: "directory_index.html" does not work

2009-01-09 Thread Django

#9993: "directory_index.html" does not work
+---
  Reporter:  Gurur  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Gurur):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Documentation
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9993: "directory_index.html" does not work

2009-01-09 Thread Django

#9993: "directory_index.html" does not work
---+
 Reporter:  Gurur  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/howto/static-files/#howto-static-
 files

 There is instruction: "You can customize the index view by creating a
 template called static/directory_index.html."

 It should be: "You can customize the index view by creating a template
 called static/directory_index."

 At least that's how it works with me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9992: get_profile / get_model issue, capitalisation of AUTH_PROFILE_MODULE

2009-01-09 Thread Django

#9992: get_profile / get_model issue, capitalisation of AUTH_PROFILE_MODULE
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> Full email discussion from: http://groups.google.com/group/django-
> users/browse_thread/thread/493e0c048dd07e46/bf8a13a685d81c75?lnk=gst=get_profile#bf8a13a685d81c75
>
> The link to the faulty documentation is given at the very end of this
> entry.
>
> Dear all,
>
> I have difficulties with the get_profile to link my Profile class with
> the inbuilt User object.
>
> The error message (which can be obtained through the 'chatroom' view
> shown below, or via the shell) is:
>
> ---
> AttributeErrorTraceback (most recent call
> last)
>
> /Users/fangohr/local/hg/scico_web/debug/mysite/ in
> ()
>
> /Library/Frameworks/Python.framework/Versions/4.0.30002/lib/python2.5
> /site-packages/django/contrib/auth/models.pyc in get_profile(self)
> 291 app_label, model_name =
> settings.AUTH_PROFILE_MODULE.split('.')
> 292 model = models.get_model(app_label, model_name)
> --> 293 self._profile_cache =
> model._default_manager.get(user__id__exact=self.id)
> 294 except (ImportError, ImproperlyConfigured):
> 295 raise SiteProfileNotAvailable
>
> AttributeError: 'NoneType' object has no attribute '_default_manager'
>

> This indicates that models.get_model() does return None, but I don't know
> why.
>
> I have in settings.py:
> AUTH_PROFILE_MODULE = 'people.profile'
> which I believe is the right entry.
>

> For clarity, I have created a small django-site that can be downloaded in
> a tar file as:
>
> http://www.soton.ac.uk/~fangohr/geheim/django/get_profile/debug.tar.gz
>
> or can be viewed online in the untarred version at
>
> http://www.soton.ac.uk/~fangohr/geheim/django/get_profile/debug
>
> I summarise the most important elements below (so that this email can
> stand on its own for the archives):
>

> mysite/People/models.py contains:
>
> #---
> from django.contrib.auth.models import User
> from django.db import models
>
> class Profile(models.Model):
> user = models.ForeignKey(User,unique=True)
> homepageURL=models.URLField('homepage',blank=True)
>
> class Admin:
> pass
> #---
>
> The corresponding view (which fails) is in mysite/People/views.py:
> #---
> from django.contrib.auth.models import User
> from django.contrib.auth.decorators import login_required
>

> def chatrooms(request):
> u = User.objects.get(pk=1) # Get the first user
> user_address = u.get_profile().homepageURL
> #at this point we get an error, equivalent to shell example
> #---
>
> The mysite/settings.py reads
>
> #---
> # Django settings for mysite project.
>
> DEBUG = True
> TEMPLATE_DEBUG = DEBUG
>
> ADMINS = (
> # ('Your Name', 'your_em...@domain.com'),
> )
>
> MANAGERS = ADMINS
>
> DATABASE_ENGINE = 'sqlite3'   # 'postgresql_psycopg2',
> 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> DATABASE_NAME = 'test.dat' # Or path to database file if
> using sqlite3.
> DATABASE_USER = '' # Not used with sqlite3.
> DATABASE_PASSWORD = '' # Not used with sqlite3.
> DATABASE_HOST = '' # Set to empty string for localhost. Not
> used with sqlite3.
> DATABASE_PORT = '' # Set to empty string for default. Not
> used with sqlite3.
>
> # Local time zone for this installation. Choices can be found here:
> # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
> # although not all choices may be available on all operating systems.
> # If running in a Windows environment this must be set to the same as
> your
> # system time zone.
> TIME_ZONE = 'America/Chicago'
>
> # Language code for this installation. All choices can be found here:
> # http://www.i18nguy.com/unicode/language-identifiers.html
> LANGUAGE_CODE = 'en-us'
>
> SITE_ID = 1
>
> # If you set this to False, Django will make some optimizations so as not
> # to load the internationalization machinery.
> USE_I18N = True
>
> # Absolute path to the directory that holds media.
> # Example: "/home/media/media.lawrence.com/"
> MEDIA_ROOT = ''
>
> # URL that handles the media served from MEDIA_ROOT. Make sure to use a
> # trailing slash if

Re: [Django] #9991: manage.py inspectdb guesses TextField on postgres' real column

2009-01-09 Thread Django

#9991: manage.py inspectdb guesses TextField on postgres' real column
+---
  Reporter:  Adys   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> Using python manage.py inspectdb outputs a models.TextField type as guess
> for every 'real' (float4) column when using postgresql (psycopg2).
> Example:
> modifier_float = models.TextField() # This field type is a guess.
>
> Quick fix: Append "700: 'FloatField'" to postgres' introspection.py's
> data_types_reverse dict. SVN is acting weird and I don't really know
> django's underlying codebase, so I rather let someone else patch this (or
> explain why it's intended).

New description:

 Using python manage.py inspectdb outputs a models.TextField type as guess
 for every 'real' (float4) column when using postgresql (psycopg2).
 Example:

 {{{
 modifier_float = models.TextField() # This field type is a guess.
 }}}

 Quick fix: Append "700: 'FloatField'" to postgres' introspection.py's
 data_types_reverse dict. SVN is acting weird and I don't really know
 django's underlying codebase, so I rather let someone else patch this (or
 explain why it's intended).

Comment:

 (edited description)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9724 - django/trunk/django/conf/locale/pl/LC_MESSAGES

2009-01-09 Thread noreply


Author: zgoda
Date: 2009-01-09 03:57:53 -0600 (Fri, 09 Jan 2009)
New Revision: 9724

Modified:
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
Log:
Updated Polish translation: fixed typo and one missing translation


Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-01-08 
10:38:40 UTC (rev 9723)
+++ django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-01-09 
09:57:53 UTC (rev 9724)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-23 21:07+0100\n"
+"POT-Creation-Date: 2009-01-09 10:43+0100\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -325,13 +325,13 @@
 msgid "No fields changed."
 msgstr "Żadne pole nie zmienione."
 
-#: contrib/admin/options.py:417 contrib/auth/admin.py:51
+#: contrib/admin/options.py:417 contrib/auth/admin.py:61
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr "%(name)s \"%(obj)s\" dodany pomyślnie."
 
 #: contrib/admin/options.py:421 contrib/admin/options.py:454
-#: contrib/auth/admin.py:59
+#: contrib/auth/admin.py:69
 msgid "You may edit it again below."
 msgstr "Możesz ponownie edytować wpis poniżej."
 
@@ -431,12 +431,12 @@
 msgid "%s administration"
 msgstr "%s - administracja"
 
-#: contrib/admin/util.py:138
+#: contrib/admin/util.py:145
 #, python-format
 msgid "One or more %(fieldname)s in %(name)s: %(obj)s"
 msgstr "Jedno lub więcej %(fieldname)s w %(name)s: %(obj)s"
 
-#: contrib/admin/util.py:143
+#: contrib/admin/util.py:150
 #, python-format
 msgid "One or more %(fieldname)s in %(name)s:"
 msgstr "Jedno lub więcej %(fieldname)s w %(name)s:"
@@ -772,7 +772,7 @@
 
 #: contrib/admin/templates/registration/logged_out.html:10
 msgid "Log in again"
-msgstr "Zaloguj ponownie"
+msgstr "Zaloguj się ponownie"
 
 #: contrib/admin/templates/registration/password_change_done.html:4
 #: contrib/admin/templates/registration/password_change_form.html:4
@@ -916,7 +916,7 @@
 msgid "Reset my password"
 msgstr "Zresetuj moje hasło"
 
-#: contrib/admin/templatetags/admin_list.py:284
+#: contrib/admin/templatetags/admin_list.py:285
 msgid "All dates"
 msgstr "Wszystkie daty"
 
@@ -1164,15 +1164,15 @@
 msgid "Groups"
 msgstr "Grupy"
 
-#: contrib/auth/admin.py:64
+#: contrib/auth/admin.py:74
 msgid "Add user"
 msgstr "Dodaj użytkownika"
 
-#: contrib/auth/admin.py:90
+#: contrib/auth/admin.py:100
 msgid "Password changed successfully."
 msgstr "Hasło zostało zmienione pomyślnie."
 
-#: contrib/auth/admin.py:96
+#: contrib/auth/admin.py:106
 #, python-format
 msgid "Change password: %s"
 msgstr "Zmień hasło: %s"
@@ -3061,7 +3061,7 @@
 
 #: contrib/localflavor/sk/sk_districts.py:34
 msgid "Kosice - okolie"
-msgstr "Koszyce - okolie"
+msgstr "Koszyce - okolice"
 
 #: contrib/localflavor/sk/sk_districts.py:35
 msgid "Krupina"
@@ -3699,7 +3699,7 @@
 msgid "sites"
 msgstr "strony"
 
-#: db/models/fields/__init__.py:348 db/models/fields/__init__.py:683
+#: db/models/fields/__init__.py:348 db/models/fields/__init__.py:692
 msgid "This value must be an integer."
 msgstr "Ta wartość musi być liczbą całkowitą."
 
@@ -3734,16 +3734,20 @@
 msgid "This value must be a decimal number."
 msgstr "Ta wartość musi być liczbą dziesiętną."
 
-#: db/models/fields/__init__.py:719
+#: db/models/fields/__init__.py:668
+msgid "This value must be a float."
+msgstr "Ta wartość musi być liczbą rzeczywistą."
+
+#: db/models/fields/__init__.py:728
 msgid "This value must be either None, True or False."
 msgstr ""
 "Ta wartość musi być jedną z None (nic), True (prawda) lub False (fałsz)."
 
-#: db/models/fields/__init__.py:817 db/models/fields/__init__.py:831
+#: db/models/fields/__init__.py:826 db/models/fields/__init__.py:840
 msgid "Enter a valid time in HH:MM[:ss[.uu]] format."
 msgstr "Proszę wpisać poprawną godzinę w formacie HH:MM[:ss[.uu]]."
 
-#: db/models/fields/related.py:761
+#: db/models/fields/related.py:760
 msgid ""
 "Hold down \"Control\", or \"Command\" on a Mac, to select more than one."
 msgstr ""
@@ -3866,7 +3870,7 @@
 msgstr ""
 "Wybierz poprawną wartość. %(value)s nie jest jednym z dostępnych wyborów."
 
-#: forms/fields.py:697 forms/fields.py:758 forms/models.py:714
+#: forms/fields.py:697 forms/fields.py:758 forms/models.py:715
 msgid "Enter a list of values."
 msgstr "Podaj listę wartości."
 
@@ -3888,15 +3892,15 @@
 msgid "%(model_name)s with this %(field_label)s already exists."
 msgstr "%(field_label)s już istnieje w %(model_name)s."
 
-#: forms/models.py:581
+#: forms/models.py:588
 msgid "The inline foreign key

[Django] #9992: get_profile / get_model issue, capitalisation of AUTH_PROFILE_MODULE

2009-01-09 Thread Django

#9992: get_profile / get_model issue, capitalisation of AUTH_PROFILE_MODULE
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Full email discussion from: http://groups.google.com/group/django-
 
users/browse_thread/thread/493e0c048dd07e46/bf8a13a685d81c75?lnk=gst=get_profile#bf8a13a685d81c75

 The link to the faulty documentation is given at the very end of this
 entry.

 Dear all,

 I have difficulties with the get_profile to link my Profile class with
 the inbuilt User object.

 The error message (which can be obtained through the 'chatroom' view
 shown below, or via the shell) is:

 ---
 AttributeErrorTraceback (most recent call
 last)

 /Users/fangohr/local/hg/scico_web/debug/mysite/ in
 ()

 /Library/Frameworks/Python.framework/Versions/4.0.30002/lib/python2.5
 /site-packages/django/contrib/auth/models.pyc in get_profile(self)
 291 app_label, model_name =
 settings.AUTH_PROFILE_MODULE.split('.')
 292 model = models.get_model(app_label, model_name)
 --> 293 self._profile_cache =
 model._default_manager.get(user__id__exact=self.id)
 294 except (ImportError, ImproperlyConfigured):
 295 raise SiteProfileNotAvailable

 AttributeError: 'NoneType' object has no attribute '_default_manager'


 This indicates that models.get_model() does return None, but I don't know
 why.

 I have in settings.py:
 AUTH_PROFILE_MODULE = 'people.profile'
 which I believe is the right entry.


 For clarity, I have created a small django-site that can be downloaded in
 a tar file as:

 http://www.soton.ac.uk/~fangohr/geheim/django/get_profile/debug.tar.gz

 or can be viewed online in the untarred version at

 http://www.soton.ac.uk/~fangohr/geheim/django/get_profile/debug

 I summarise the most important elements below (so that this email can
 stand on its own for the archives):


 mysite/People/models.py contains:

 #---
 from django.contrib.auth.models import User
 from django.db import models

 class Profile(models.Model):
 user = models.ForeignKey(User,unique=True)
 homepageURL=models.URLField('homepage',blank=True)

 class Admin:
 pass
 #---

 The corresponding view (which fails) is in mysite/People/views.py:
 #---
 from django.contrib.auth.models import User
 from django.contrib.auth.decorators import login_required


 def chatrooms(request):
 u = User.objects.get(pk=1) # Get the first user
 user_address = u.get_profile().homepageURL
 #at this point we get an error, equivalent to shell example
 #---

 The mysite/settings.py reads

 #---
 # Django settings for mysite project.

 DEBUG = True
 TEMPLATE_DEBUG = DEBUG

 ADMINS = (
 # ('Your Name', 'your_em...@domain.com'),
 )

 MANAGERS = ADMINS

 DATABASE_ENGINE = 'sqlite3'   # 'postgresql_psycopg2',
 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
 DATABASE_NAME = 'test.dat' # Or path to database file if using
 sqlite3.
 DATABASE_USER = '' # Not used with sqlite3.
 DATABASE_PASSWORD = '' # Not used with sqlite3.
 DATABASE_HOST = '' # Set to empty string for localhost. Not
 used with sqlite3.
 DATABASE_PORT = '' # Set to empty string for default. Not used
 with sqlite3.

 # Local time zone for this installation. Choices can be found here:
 # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
 # although not all choices may be available on all operating systems.
 # If running in a Windows environment this must be set to the same as your
 # system time zone.
 TIME_ZONE = 'America/Chicago'

 # Language code for this installation. All choices can be found here:
 # http://www.i18nguy.com/unicode/language-identifiers.html
 LANGUAGE_CODE = 'en-us'

 SITE_ID = 1

 # If you set this to False, Django will make some optimizations so as not
 # to load the internationalization machinery.
 USE_I18N = True

 # Absolute path to the directory that holds media.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = ''

 # URL that handles the media served from MEDIA_ROOT. Make sure to use a
 # trailing slash if there is a path component (optional in other cases).
 # Examples: "http://media.lawrence.com;, "http://example.com/media/;
 MEDIA_URL = ''

 # URL prefix for admin media -- CSS, JavaScript and images. Make sure to
 use a
 # trailing slash.
 # Examples: "http://foo.com/media/;, "/media/".
 ADMIN_MEDIA_PREFIX = '/media/'

 AUTH_PROFILE_MODULE = 'people.profile'

 # Make this unique, and don't share it

Re: [Django] #6064: Allow database connection initialization commands

2009-01-09 Thread Django

#6064: Allow database connection initialization commands
---+
  Reporter:  jacob | Owner:  floguy
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by euphoria):

 * cc: michael.gre...@gmail.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9991: manage.py inspectdb guesses TextField on postgres' real column

2009-01-09 Thread Django

#9991: manage.py inspectdb guesses TextField on postgres' real column
---+
 Reporter:  Adys   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Using python manage.py inspectdb outputs a models.TextField type as guess
 for every 'real' (float4) column when using postgresql (psycopg2).
 Example:
 modifier_float = models.TextField() # This field type is a guess.

 Quick fix: Append "700: 'FloatField'" to postgres' introspection.py's
 data_types_reverse dict. SVN is acting weird and I don't really know
 django's underlying codebase, so I rather let someone else patch this (or
 explain why it's intended).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

51 matches

Mail list logo