Re: Error in formfield in django.db.models.field
On Nov 13, 11:55 pm, Ric wrote:
> the field class define this code
>
> def formfield(self, form_class=forms.CharField, **kwargs):
> """
> Returns a django.forms.Field instance for this database Field.
> """
> defaults = {'required': not self.blank,
> 'label': capfirst(self.verbose_name),
> 'help_text': self.help_text}
> if self.has_default():
> if callable(self.default):
> defaults['initial'] = self.default
> defaults['show_hidden_initial'] = True
> else:
> defaults['initial'] = self.get_default()
> if self.choices:
> # Fields with choices get special treatment.
> include_blank = (self.blank or
> not (self.has_default() or 'initial' in
> kwargs))
> defaults['choices'] =
> self.get_choices(include_blank=include_blank)
> defaults['coerce'] = self.to_python
> if self.null:
> defaults['empty_value'] = None
> form_class = forms.TypedChoiceField
> # Many of the subclass-specific formfield arguments
> (min_value,
> # max_value) don't apply for choice fields, so be sure to
> only pass
> # the values that TypedChoiceField will understand.
> for k in kwargs.keys():
> if k not in ('coerce', 'empty_value', 'choices',
> 'required',
> 'widget', 'label', 'initial',
> 'help_text',
> 'error_messages', 'show_hidden_initial'):
> del kwargs[k]
> defaults.update(kwargs)
> return form_class(**defaults)
>
> this code says
> if self.choices:
> form_class = forms.TypedChoiceField
>
> this means that if you have a field that got choices, even if you pass
> during the super an argument different than forms.TypedChoiceField,
> you'll always get forms.TypedChoiceField
>
> must be defaults["form_class"] = forms.TypedChoiceField
do you mean something like:
if self.choices:
if 'form_class' in defaults:
form_class = defaults['form_class']
else:
form_class = forms.TypedChoiceField
-Preston
form_class =
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Error in formfield in django.db.models.field
yes but definitely not the current code, because i cannot subclass
with super
On 14 Nov, 15:46, ptone wrote:
> On Nov 13, 11:55 pm, Ric wrote:
>
>
>
>
>
>
>
>
>
> > the field class define this code
>
> > def formfield(self, form_class=forms.CharField, **kwargs):
> > """
> > Returns a django.forms.Field instance for this database Field.
> > """
> > defaults = {'required': not self.blank,
> > 'label': capfirst(self.verbose_name),
> > 'help_text': self.help_text}
> > if self.has_default():
> > if callable(self.default):
> > defaults['initial'] = self.default
> > defaults['show_hidden_initial'] = True
> > else:
> > defaults['initial'] = self.get_default()
> > if self.choices:
> > # Fields with choices get special treatment.
> > include_blank = (self.blank or
> > not (self.has_default() or 'initial' in
> > kwargs))
> > defaults['choices'] =
> > self.get_choices(include_blank=include_blank)
> > defaults['coerce'] = self.to_python
> > if self.null:
> > defaults['empty_value'] = None
> > form_class = forms.TypedChoiceField
> > # Many of the subclass-specific formfield arguments
> > (min_value,
> > # max_value) don't apply for choice fields, so be sure to
> > only pass
> > # the values that TypedChoiceField will understand.
> > for k in kwargs.keys():
> > if k not in ('coerce', 'empty_value', 'choices',
> > 'required',
> > 'widget', 'label', 'initial',
> > 'help_text',
> > 'error_messages', 'show_hidden_initial'):
> > del kwargs[k]
> > defaults.update(kwargs)
> > return form_class(**defaults)
>
> > this code says
> > if self.choices:
> > form_class = forms.TypedChoiceField
>
> > this means that if you have a field that got choices, even if you pass
> > during the super an argument different than forms.TypedChoiceField,
> > you'll always get forms.TypedChoiceField
>
> > must be defaults["form_class"] = forms.TypedChoiceField
>
> do you mean something like:
>
> if self.choices:
> if 'form_class' in defaults:
> form_class = defaults['form_class']
> else:
> form_class = forms.TypedChoiceField
>
> -Preston
> form_class =
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Multi-DB support within transaction middleware
There's merit in both the responses. Since it's trivial to write your own transaction middleware, I would say the most important thing is to document that the middleware only affects your 'default' database. Then it's up to the developer to decide if they need anything further. On Sun, Nov 13, 2011 at 7:05 PM, Yo-Yo Ma wrote: > Before voting for more magic to the transaction middleware, I'd vote > to remove it altogether. Explicit is surely better than implicit in > this case. The admin already uses commit_on_success, etc. > > On Oct 18, 1:22 pm, David Winterbottom > wrote: > > The current implementation of django.middleware.TransactionMiddleware > does > > not create a transaction for each database, only the default one > > defined by DEFAULT_DB_ALIAS > > -https://code.djangoproject.com/browser/django/trunk/django/db/utils.py. > > Shouldn't the middleware manage a transaction for each database defined > in > > the DATABASES setting? > > > > I discovered this while debugging some caching issues with the > johnnycache > > library, which saves cached querysets when committing. In my case, all > > requests to databases other than default were not being cached. > > > > Happy to supply a patch and tests if this is sensible. > > -- > > *Dr. David Winterbottom* > > Head of Programming > > > > Tangent Labs > > 84-86 Great Portland Street > > London W1W 7NR > > England, UK > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- *Dr. David Winterbottom* Head of Programming Tangent Labs 84-86 Great Portland Street London W1W 7NR England, UK -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Using Django DB connections outside request
I am wondering about how to properly close connections if you use the ORM outside requests. For requests this is done in django/db/ __init__.py: """ # Register an event that closes the database connection # when a Django request is finished. def close_connection(**kwargs): for conn in connections.all(): conn.close() signals.request_finished.connect(close_connection) """ But naturally this is not called if you use ORM outside of requests. The DatabaseWrapper is a threading.local subclass, and it has a reference to the real DB connection. The DatabaseWrapper is referenced from django.db.connections. This means there will be a reference to each different DB connection hanging around for as long as the thread is running. And this means the connection is never closed if you don't explicitly close it. To me it seems this could easily lead to idle connections hanging around, or worse, idle in transaction connections hanging around. Is proper connection handling outside requests documented somewhere? I couldn't find anything. But I did found this stack overflow thread: http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections The idle-in-transaction part of the stack-overflow thread seems to be corrected: https://code.djangoproject.com/ticket/9964 It seems some documentation would be welcome as well as a nice function decorator to use outside requests. @handle_connections or maybe @commit_on_success(close_connections=True). - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
mark_safe(media) in django admin
a minor bug in django admin. in django.contrib.admin.options mark_safe is called to render media. in add_view and change_view we can find mark_safe(media) in changelist_view media is injected as an object (without mark_safe) i propose to pass the media object to the template (without mark_safe), because i use a context_processor that adds media. so i check in the context if there is 'media' key, and then merge my own list of javascript and css with the existing django media. but i cannot do this if the media object is rendered before it is passed to the context processor. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Error in formfield in django.db.models.field
form_class is not in kwargs if the method is declared like this
def formfield(self, form_class=forms.CharField, **kwargs):
a possible solution is to use a code like this
def formfield(self, **kwargs):
form_class = kwargs.pop("form_class", self.choices and
forms.TypedChoiceField or forms.CharField)
in that way is no form_class is passed, a default form_class is
defined (TypedChoiceField or CharField)
On 14 Nov, 21:22, Ric wrote:
> yes but definitely not the current code, because i cannot subclass
> with super
>
> On 14 Nov, 15:46, ptone wrote:
>
>
>
>
>
>
>
> > On Nov 13, 11:55 pm, Ric wrote:
>
> > > the field class define this code
>
> > > def formfield(self, form_class=forms.CharField, **kwargs):
> > > """
> > > Returns a django.forms.Field instance for this database Field.
> > > """
> > > defaults = {'required': not self.blank,
> > > 'label': capfirst(self.verbose_name),
> > > 'help_text': self.help_text}
> > > if self.has_default():
> > > if callable(self.default):
> > > defaults['initial'] = self.default
> > > defaults['show_hidden_initial'] = True
> > > else:
> > > defaults['initial'] = self.get_default()
> > > if self.choices:
> > > # Fields with choices get special treatment.
> > > include_blank = (self.blank or
> > > not (self.has_default() or 'initial' in
> > > kwargs))
> > > defaults['choices'] =
> > > self.get_choices(include_blank=include_blank)
> > > defaults['coerce'] = self.to_python
> > > if self.null:
> > > defaults['empty_value'] = None
> > > form_class = forms.TypedChoiceField
> > > # Many of the subclass-specific formfield arguments
> > > (min_value,
> > > # max_value) don't apply for choice fields, so be sure to
> > > only pass
> > > # the values that TypedChoiceField will understand.
> > > for k in kwargs.keys():
> > > if k not in ('coerce', 'empty_value', 'choices',
> > > 'required',
> > > 'widget', 'label', 'initial',
> > > 'help_text',
> > > 'error_messages', 'show_hidden_initial'):
> > > del kwargs[k]
> > > defaults.update(kwargs)
> > > return form_class(**defaults)
>
> > > this code says
> > > if self.choices:
> > > form_class = forms.TypedChoiceField
>
> > > this means that if you have a field that got choices, even if you pass
> > > during the super an argument different than forms.TypedChoiceField,
> > > you'll always get forms.TypedChoiceField
>
> > > must be defaults["form_class"] = forms.TypedChoiceField
>
> > do you mean something like:
>
> > if self.choices:
> > if 'form_class' in defaults:
> > form_class = defaults['form_class']
> > else:
> > form_class = forms.TypedChoiceField
>
> > -Preston
> > form_class =
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: mark_safe(media) in django admin
On 14 nov. 2011, at 23:15, Ric wrote: > a minor bug in django admin. Could you open a ticket in our bug tracker? https://code.djangoproject.com/newticket Thanks, -- Aymeric Augustin. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
