Re: Backwards compatibility and field validation
A few cents... First, a project wide settings to control this behaviour would be complex with pluggable apps. Some apps might expect global valodation enabled, but some might expect it disabled. We should have model.save validating by default and have a flag to turn it off. I think it's reasonable to assume that by default we want our data to be consistent. Regards, Luciano Pacheco On 17/10/2013 10:47 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leem...@simplicitymedialtd.co.uk> wrote: > Thank you for the detailed reply, much appreciated. > > I think the problem isn't just storing model validations with migrations, > because it's probably good practice for any developer to assume that field > data may be invalid (i.e. manual field/table changes, unknown validation > bugs from previous releases, buggy migration scripts etc). And a > for/model.save() loop would only work if auto-repair was feasible, in which > case the developer has to decide how to handle validation failures at > certain points in the code. The typical scenarios you'd handle when > encountering invalid data would be to ignore, repair or error - depending > on where you are within the code. > > The approaches that come to mind are; > > 1) save(validate=True) > This still feels superfluous because we can just call full_clean() before > save(). > > 2) full_clean() then save() > This works but you have to manually check the errors to see if it was old > or new data that causes validation > > 3) save(validate_only_changes=True) OR > full_clean(validate_only_changes=True) > Feels a bit better as it allows me to handle background jobs gracefully, > say a cron that is failing on a record that it doesn't know/need at that > point of execution. > > 4) CharField(validate_old=True) > This would not allow context specific handling (i.e. we want to enforce > validate old if we have a user request because we can ask them for updated > info, but do not enforce validate when inside a background job which does > not have the necessary context to request repair) > > From what I can tell, 3 would be a good approach based on the logic of > making it easier for the developer to decide how the failed validation > should be handled at certain points in the code. > > Do you think that `save(validate_only_changes=True)` would be a good > approach (worthy of a patch), or am I over-engineering this problem? > > Cal > > > On Thu, Oct 17, 2013 at 12:08 AM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> >> On Wed, Oct 16, 2013 at 12:15 AM, Cal Leeming [Simplicity Media Ltd] < >> cal.leem...@simplicitymedialtd.co.uk> wrote: >> >>> Sorry I should have made myself a little more clear. >>> >>> When I said "invalidating data inside your models" I was referring to >>> any previous data that was saved when the validator was set to a minimum >>> length of 4 characters. By then changing the validator to be 5 characters, >>> you are effectively breaking save() on any data that was saved before that >>> point, and the ability to fix the model data may not be available in that >>> specific save() context. For example, a cron job that updates a >>> "last_checked" field on the user would not necessarily have data relevant >>> to changes in the users phone number (which could have its min/max length >>> changed at any point in the validators life time). >>> >>> Hope that makes more sense >>> >>> Your analysis is correct, but you're possibly over thinking this a bit. >> >> Consider a world in which model validation *was* on by default. You write >> some models with a char field, and you insert some data. All valid, all >> saved successfully. Now you change your models and add a validation >> condition. You've just exposed yourself to exactly the same situation, >> without feature-level backwards compatibility ever being part of the >> picture. >> >> What this highlights is that migration needs to be part of the whole >> solution. At the very least, as part of adding default model validation, >> we'd need to document the fact that all existing data must be assumed to be >> potentially invalid, and provide an easy way to force validation. >> Unfortunately, there's not sure I see any easy way to do this other than a >> "for model in database: model.save()" loop. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, se
Memcache not caching big values (> 1Mb)
Hi all, Memcache backend, using python-memcache silently ignores data bigger than 1Mb. This is more serious on using cache for pages (full body) where it's more likely to have larger data being cached. Also, larger pages usually are the ones that need more cache, because their more costly to generate. I've propose a fix that address this issue and 2 more: 1 - Compress cache data https://code.djangoproject.com/ticket/16116 Because body page has a good compression rate this feature helps a lot on this issue. 2 - Pickle protocol https://code.djangoproject.com/ticket/19810#no2 Most of django backends uses higher pickle protocol, but it isn't true for Memcache 3 - cache_db session "forgetting" big values https://code.djangoproject.com/ticket/16358 Here is the pull request to address these issues: https://github.com/django/django/pull/736/commits It has changes in the docs and memcache backends, but there isn't any test, because I couldn't figure out how to test them. :( Any advice on how to test them? Any feedback is welcome, I'm willing to make any necessary changes to get it on the 1.6 train :) [], -- Luciano Pacheco blog.lucmult.com.br -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On Thu, Jan 3, 2013 at 8:17 AM, Florian Apolloner <f.apollo...@gmail.com>wrote:
> * local_settings is imo a bad pattern as they can't easily override
> anything without copying it completely into the local_settings (think of
> all the settings which are dicts like DATABASES and CACHES)
I use this way to allow variable changes:
try:
execfile('local_settings.py', globals(), locals())
except IOError:
pass
Mostly because I want in development: new apps, middlewares, so these are
possible:
INSTALLED_APPS += ('debug_toolbar', 'django_extensions', 'devserver')
MIDDLEWARE_CLASSES += ('debug_toolbar.middleware.DebugToolbarMiddleware',)
On the main topic, I'm in favor of PROJECT_ROOT settings, it's a common
practice, and isn't that bad, once in production it can be a mount point or
overwritten on local_settings.py
[],
--
Luciano Pacheco
blog.lucmult.com.br
--
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: Django-nonrel patches
On Jun 27, 2012 7:12 AM, "Chris Northwood" <cnorthw...@gmail.com> wrote: > > On 26 June 2012 22:07, Adam "Cezar" Jenkins <emperorce...@gmail.com> wrote: > > > I have to agree, that's the big one. Though I the ecosystem of 3rd party > > apps is what makes using Django so great. If there is one ORM for 99% of > > the apps out there, and only one that works Mongo, then the only real use > > case of Django is going to be a system where you're using a RDBM > > in combination with Mongo. > > Surely that's what it needs though, an 'ORM' and an 'Object-Document > Mapper' at some point. What's the advantage of trying to shoehorn > MongoDB to work with an ORM, when it's not relational, and as it has > to be hidden behind the same abstraction layer as a RDBMS, you lose > the benefits of it being non-relational? I agree that they are 2 different concepts (ORM and documents), however the namings in Django API looks like it might work well even for handling documents <=> objects. User.objects.all() User.objects.filter(email=email) Looking at this there is nothing telling about the relational concepts behind it. Of course for all relations operations (foreings, many to many, etc) the api might start to differ . If Django has a support for the basic api but with admin and loging working I think is a good step forward. After that we can wait for a better common sense about relations between documents emerge. We have been waiting this common sense to emerge without any builtin support, maybe with the basic api would have more people involved with. []. Luciano Pacheco -- 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: extra files in startproject
On Fri, Apr 13, 2012 at 5:15 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 12 avr. 2012, at 23:16, Aymeric Augustin wrote: > [...] > So a documentation fix might not be sufficient to eradicate the problem. > Could we add this in a pre-install hook in setup.py? > > try: >import django > except ImportError: >pass > else: > print "It appears that Django %s is already installed." % > django.get_version() > print "If you want to upgrade Django, please remove the existing > installation first." > sys.exit(1) > This "import django" will work even when django is not installed, because usually "python setup.py " is ran from checkout of django, that contains the valid folder (python package) named "django". So, this "import django" will import relative to current directory and will work. [], -- Luciano Pacheco blog.lucmult.com.br -- 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: extra files in startproject
On Fri, Apr 13, 2012 at 8:30 AM, Carl Meyer <c...@oddbird.net> wrote: > Hi Alex, > > On 04/12/2012 04:23 PM, Alex Ogier wrote: > > On Apr 12, 2012 6:16 PM, "Carl Meyer" <c...@oddbird.net > > <mailto:c...@oddbird.net>> wrote: > [...] > I still think the right solution is to encourage (via the documentation) > installation practices that work reliably, not to try to apply piecemeal > workarounds to specific breakages caused by installation practices that > don't work reliably (and still won't after the piecemeal workaround). Please add a note how to detect Django version and path: >>> import django >>> django.VERSION (1, 3, 0, 'final', 0) >>> django.__file__ '/home/lucianopacheco/src/tmp_py/local/lib/python2.7/site-packages/django/__init__.pyc' So, it will be much more clear to people not familiar with python installation structure to understand what "site-packages" means. [], -- Luciano Pacheco blog.lucmult.com.br -- 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: authentication by email
On Fri, Mar 16, 2012 at 10:05 AM, Carl Meyer <c...@oddbird.net> wrote: [...] > I am not sure whether this should happen as a separate step or not. In > an ideal world, we would have a longer username field. In the real > world, we have to balance the benefit against the cost, and requiring a > schema migration from practically every Django installation on the > planet would IMO be the most significant backwards-incompatible change > Django has ever shipped, at least since Django 1.0. It is not at all > clear to me that the status quo, bad as it is, is worse than this cure. > I can't understand how bad is a database schema change. Almost all web site/applications need to change they database schema. Ok, in some cases there are people that don't update their databases, but I think this cases aren't willing to update their version of software as well. If the installed a web site/app is too small to be afraid to update, the database change will be fast enough to cause a minimal downtime. If the installed a web site/app is too big, the sysadmin/devops already know how to couple with database schema changes. And it's likely that they have a test/staging/validation environment to analyse the changes before production. This current limitation doesn't bother me, but all this concerned about database schema change does. :-) Regards, -- Luciano Pacheco blog.lucmult.com.br -- 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.
DoS using POST via hash algorithm collision
Hi all, Have you guys seen this? http://www.ocert.org/advisories/ocert-2011-003.html PDF with some more explanation: http://www.nruns.com/_downloads/advisory28122011.pdf Regards, -- Luciano Pacheco blog.lucmult.com.br -- 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: Small problem with HttpResponseRedirect
On Tue, Dec 6, 2011 at 9:00 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Not sure if this should have a bug ticket raised or not.. wanted to get > core devs thoughts. > > > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" > HttpResponseRedirect(_redir) > returns "Location: > http://your/path/with/an/extra/slash/for/whatever/reason; > _redir var has an ambiguous string. Is it malformed, missing the "protocol:" like "http:" or "https:" . Or "malformed" in URI's path part? So, it seems not obvious to handle it. Let's refuse the temptation to guess. ;-) Regards, -- Luciano Pacheco blog.lucmult.com.br -- 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.
