Re: Backwards compatibility and field validation

One problem with it as you've found is that you sometimes do want control over it on a per-model or even per-instance (per-save) basis. One way to deal with this is to create something like the following that you can extend in your models: class ValidatedModel(models.Model): def save(self,

Re: ImportError: cannot import name actions

Hi Rob, If you're able to generate a cyclic import error in 1.6b4, then that's definitely a release blocker. The first step is obviously to reproduce the bug. This isn't something I've seen in my testing, and that particular file (sites.py) hasn't changed in 5 months (at least, not in the 1.6

Re: Django 1.6 release timeline

Hey guys! Any updates? -- 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

Re: ImportError: cannot import name actions

On Tue, Oct 15, 2013, rok wrote: >I thought since the 1.6 release is in the final stretch this might be >somewhat related to bugfixing. I posted it to the users forum. Well it could indeed be a bug of course. Is it feasible for your to reduce it to something easily

Re: ImportError: cannot import name actions

Thanks Daniele, I thought since the 1.6 release is in the final stretch this might be somewhat related to bugfixing. I posted it to the users forum. Rok On Tuesday, October 15, 2013 5:11:36 PM UTC+2, Daniele Procida wrote: > > On Tue, Oct 15, 2013, rok wrote: > > >I have

Re: Backwards compatibility and field validation

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

Re: Backwards compatibility and field validation

I've been thinking about this a little bit more, and it seems that the design approach of validating on save() is not entirely correct. For example, say you have a validator that ensures a field must be at least 4 characters long, and a few months later the validation is then changed to be 5

Re: ImportError: cannot import name actions

On Tue, Oct 15, 2013, rok wrote: >I have recently been testing the 1.6b4 tag with a new app we are >writing, using apache and wsgi. However, I could not get rid of the >following issue happening on every request: You'll be better off asking this question over on the Django

ImportError: cannot import name actions

I have recently been testing the 1.6b4 tag with a new app we are writing, using apache and wsgi. However, I could not get rid of the following issue happening on every request: ... [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] File

Re: Specifying the field index types

I believe the basics of how to make it migration friendly would simply be to make sure it is given in the field's `deconstruct` method. The Index class may also need to provide a `as_remove_sql(self, qn, connection)` method which would return the relevant `DROP INDEX` command for the db. I think

Re: Specifying the field index types

On Monday, September 23, 2013 5:36:56 PM UTC+3, Zev Benjamin wrote: > > Hi, > > I'd like to be able to specify what kind of index the database should use > for a particular field. I have a proof of concept branch that works with > PostgreSQL at

Re: Feature request: New middleware method for "universal" decoration

On Tuesday, October 15, 2013 8:23:38 AM UTC+3, gavi...@gmail.com wrote: > > This topic was also discussed during the deprecation of > TransactionMiddleware and the introduction of ATOMIC_REQUESTS. The existing > middleware semantics can't guarantee that __exit__ (during > process_response)