Sporadic proxy deletion failures on mysql
Hello all, When running regressiontests.delete_regress.tests.ProxyDeleteTest and regressiontests.delete_regress.tests.ProxyOfProxyDeleteTest on mysql, sporadic IntegrityErrors would occur. This was caused by the proxy model's base model not having the proxy model as a dependency, and the sporadic nature was entirely the result of dictionary ordering going into Collector.sort() - sometimes it would be in an order that honored the constraints, sometimes it wouldn't. This was introduced, I believe, in revision 17664. I have only observed it on mysql, but it is hypothetically a universal issue. My proposed solution is simply to ensure that the proxy model's base class gets included as a dependency. I have created a ticket, https://code.djangoproject.com/ticket/17918 , and set the severity to "Release blocker", as well as supplied a patch that resolved the issue for me. If this issue is not a release blocker, or my patch is insufficient, please let me know. Regards, Nate -- 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: Tips required to run django tests configurazion for all databases
On Sat, Mar 17, 2012 at 5:33 AM, Simone Federici wrote: > oracle and postgresql have the similar performance during the tests, > > but mysql... there is some tricks to go faster the mysql suite test case? > I recently encountered this as well; for me, it was because I was using MyISAM as the backend - switching to InnoDB saw about an 8x speedup, to become comparable to postgres (it took over four hours to run under MyISAM, for reference). Which backend are you using? -- 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.
Complex aggregate and expression composition.
Hello all,
Since even before I saw Alex Gaynor's presentation "I hate the Django ORM"
(the one with the `Sum(F("end_time") - F("start_time"))` query), the problem
of complex aggregates and expressions has vexed me. So, I figured I would
try to solve it.
Originally, I started this trying to pursue a solution to ticket #14030,
but after
I took a couple of lousy shots at it, it dawned on me that the ticket would
be
better resolved as a result of solving the more general case. I realized
that
aggregates were just a special case of expressions, and that the best
solution
was going to take a refactoring of Aggregate into ExpressionNode.
I have uploaded my branch; it can be found here:
https://github.com/NateBragg/django/tree/14030
Since this is a non-trivial change, I was hoping to open the topic for
debate
here, and get some feedback before proposing my solution for inclusion.
Some particular points of note:
* I tried to preserve as much interface as possible; I didn't know how much
was considered to be more public, so generally I tried to add rather than
subtract. However, I did remove a couple things - if you see something
missing that shouldn't be, let me know.
* Currently, I'm getting the entire test suite passed on sqlite, oracle,
mysql,
postgres, and postgis. I was unable to test on oracle spatial - any help
with that would be appreciated.
* When fields are combined, they are coerced to a common type;
IntegerFields are coerced to FloatFields, which are coerced into
DecimalFields as needed. Any other kinds of combinations must be of
the same types. Also, when coerced to a DecimalField, the precision
is limited by the original DecimalField. If this is not correct, or other
coercions should be added, I'd like to correct that.
* When joins are required, they tend to be LEFT OUTER; I'd like some
feedback on this, as I'm not 100% sure its always the best behavior.
* As the aggregates are a little more complicated, on trivial cases there
is a minor reduction in performance; using djangobench, I measured
somewhere between a 3% and 8% increase in runtime.
* I don't have enough tests - mostly for a lack of creativity. What kind of
composed aggregates and expressions would you like to see? I'll add
tests for them.
Thank you all, and sorry for the above being a short book.
-- Nate Bragg
--
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: Allow changing form field properties after form creation
They don't "have" to be replaced in a subclass in the way you showed.
Perhaps it isn't perfectly DRY, but whats so bad about naming the field
explicitly? Anyhow, when it comes specifically to widgets, the Meta
class already has a 'widgets' attribute already that lets you specify that.
I would sooner have "smart" Meta class attributes to perform this
behavior declaratively than to have to do it at the __init__ level:
class Meta:
title__required = False
programs__help_text = 'Hold down Ctrl to select multiple options'
authors__required = False
confidential__widget = AdminYesNoWidget
uploader__required = False
file__widget = AdminFileWidgetWithSize
... and I don't like *that* particularly either.
Cheers,
Nate
On Thu, Apr 5, 2012 at 7:49 AM, Chris Wilson wrote:
> Hi all,
>
> I've added this as a ticket but I wanted to make sure that the core and
> forms developers have a chance to see and interact with it, so I'm posting
> it here too. You can find the ticket at: <
> https://code.djangoproject.com/ticket/18064>
>
> Currently, if I want to tweak the properties of some fields in a
> ModelForm, I have to replace them in the subclass like this:
>
> {{{
> class DocumentForm(ModelForm):
>title =
> models.Document._meta.get_field('title').formfield(required=False)
>programs =
> models.Document._meta.get_field('programs').formfield(required=False)
>authors =
> models.Document._meta.get_field('authors').formfield(required=False)
>confidential =
> models.Document._meta.get_field('confidential').formfield(widget=AdminYesNoWidget)
>uploader =
> models.Document._meta.get_field('uploader').formfield(required=False)
>file =
> models.Document._meta.get_field('file').formfield(widget=AdminFileWidgetWithSize)
> }}}
>
> This is very bulky to just change some properties. The problem is that the
> field copies some of its properties into weird places like the widget
> during initialisation:
>
> {{{
> class Field(object):
>...
>def __init__(...)
>...
>if help_text is None:
>self.help_text = u''
>else:
>self.help_text = smart_unicode(help_text)
>widget = widget or self.widget
>if isinstance(widget, type):
>widget = widget()
>
># Trigger the localization machinery if needed.
>self.localize = localize
>if self.localize:
>widget.is_localized = True
>
># Let the widget know whether it should display as required.
>widget.is_required = self.required
>
># Hook into self.widget_attrs() for any Field-specific HTML
> attributes.
>extra_attrs = self.widget_attrs(widget)
>if extra_attrs:
>widget.attrs.update(extra_attrs)
>
>self.widget = widget
> }}}
>
> If we refactored this so that all the property initialisation was done in
> setters, then we could just write:
>
> {{{
> class DocumentForm(ModelForm):
>def __init__(...)
>self['title'].required = False
>self['programs'].help_text = 'Hold down Ctrl to select multiple
> options'
>self['authors'].required = False
>self['confidential'].widget = AdminYesNoWidget
>self['uploader'].required = False
>self['file'].widget = AdminFileWidgetWithSize
> }}}
>
> Which is more concise, much clearer, and does not override things
> unnecessarily.
>
> I can write the code, but first I want to:
>
> * see if any core developers object, to avoid wasting effort
> * know how to run the Django tests and which suite(s) I should be running
> * know where to put the tests.
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> 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.
>
>
--
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: Complex aggregate and expression composition.
> I took a quick look at your patch. I don't have more time now, so just
> some quick comments:
> [...]
I think the approach you have taken is correct in general. I would
> encourage to check
> if you can somewhat easily incorporate the conditional aggregate support
> (#11305)
> into the ExpressionNode based aggreagates. It does not belong into the same
> patch, but is a good sanity check if the approach taken is extensible.
>
Thanks for taking a look! Sorry it took me so long to get back to you,
I've been quite
busy lately. I finally had two hours to rub together to try your
suggestion; I set up a
branch ( https://github.com/NateBragg/django/tree/11305 ) that implements
this
behavior using (more or less) your approach.
The difference can be found here:
https://github.com/natebragg/django/compare/natebragg:14030...natebragg:11305
I also wanted to thank you on another count, as parts of your 11305 approach
served as a launching point for my work - and even gave me a good solution
for
one of the problems I listed in my original email (regarding join
promotion), that
I have since incorporated it onto the 14030 branch.
- I am a bit scared of the type coercions. The reason is that this could
> prove to be
>hopelessly complex to get right in every case. However, I do not have
> concrete
>examples where this is in fact a problem. The default should probably
> not be an exception,
>but just returning what the database happens to give you back.
>
It could be quite complex, I agree, but it doesn't have to be. I based it
off of the
preexisting concept that Aggregates needed to know about their field types,
and whether or not they were ordinal or computed aggregate types.
So, in general what I need is other folks trying this, finding problems, or
taking
issue with my proposal. It might not be quite as exciting as user.auth,
but I
think refactoring like this needs review and feedback. I'd really love to
propose
this for inclusion, so that others could benefit from this.
As it's a couple weeks old, in case you missed my original email, I've
included it below.
Thanks,
Nate
___
> From: django-developers@googlegroups.com [
> django-developers@googlegroups.com] On Behalf Of Nate Bragg [
> jonathan.br...@alum.rpi.edu]
> Sent: Wednesday, March 21, 2012 01:27
> To: django-developers@googlegroups.com
> Subject: Complex aggregate and expression composition.
>
> Hello all,
>
> Since even before I saw Alex Gaynor's presentation "I hate the Django ORM"
> (the one with the `Sum(F("end_time") - F("start_time"))` query), the
> problem
> of complex aggregates and expressions has vexed me. So, I figured I would
> try to solve it.
>
> Originally, I started this trying to pursue a solution to ticket #14030,
> but after
> I took a couple of lousy shots at it, it dawned on me that the ticket
> would be
> better resolved as a result of solving the more general case. I realized
> that
> aggregates were just a special case of expressions, and that the best
> solution
> was going to take a refactoring of Aggregate into ExpressionNode.
>
> I have uploaded my branch; it can be found here:
>
> https://github.com/NateBragg/django/tree/14030
>
> Since this is a non-trivial change, I was hoping to open the topic for
> debate
> here, and get some feedback before proposing my solution for inclusion.
>
> Some particular points of note:
> * I tried to preserve as much interface as possible; I didn't know how much
> was considered to be more public, so generally I tried to add rather than
> subtract. However, I did remove a couple things - if you see something
> missing that shouldn't be, let me know.
> * Currently, I'm getting the entire test suite passed on sqlite, oracle,
> mysql,
> postgres, and postgis. I was unable to test on oracle spatial - any help
> with that would be appreciated.
> * When fields are combined, they are coerced to a common type;
> IntegerFields are coerced to FloatFields, which are coerced into
> DecimalFields as needed. Any other kinds of combinations must be of
> the same types. Also, when coerced to a DecimalField, the precision
> is limited by the original DecimalField. If this is not correct, or other
> coercions should be added, I'd like to correct that.
> * When joins are required, they tend to be LEFT OUTER; I'd like some
> feedback on this, as I'm not 100% sure its always the best behavior.
> * As the aggregates are a little more complicated, on trivial cases there
> is a minor reduction in performance; using djangobench, I measured
> somewhere between a 3% and 8% increase in runtime.
> * I don't have enough tests - mostly for
