Recursive model queries

Hello, I am trying to use https://github.com/heywbj/django-rest-framework-recursive I need to be able to run query on a recursive model that gives the name of the parent and child My model class RecursiveModel(models.Model): stage_title = models.CharField(max_length=255, unique=True) p

ForeignKey Fields null=True does not imply blank=True

Hi All, I just discovered some interesting behaviour in Django 1.8.4 and was wondering if this was an unexpected side effect or specifically designed behaviour. class UserProfile(models.Model): # Notice that I do not say that blank=True my_other_model = models.ForeignKey('my_app.OtherM

Re: Turn off migrations completely in Django 1.7

W dniu 25.08.2015 o 19:04, Marcin Nowak pisze: I would like to provide solid patch as a pull request, but I'm afraid that it will be rejected due to some kind of spirit, politics or something else. BR, Marcin Marcin, please - consider sharing your patch on GitHub (or similar) with a documen

Re: Turn off migrations completely in Django 1.7

On Tue, Aug 25, 2015 at 5:27 PM, Carl Meyer wrote: > To my knowledge, out of the many hundreds of > thousands of Django users, you are the first and only one to request a > way to turn off migrations entirely. > I think that's a little unfair, given that migrations are only in Django since 1.7,

Re: ForeignKey Fields null=True does not imply blank=True

On 26/08/15 11:59, khoobks wrote: > I just discovered some interesting behaviour in Django 1.8.4 and was > wondering if this was an unexpected side effect or specifically designed > behaviour. That behaviour is intended and documented[0]. blank and null working on completely different levels. bla

Re: ForeignKey Fields null=True does not imply blank=True

That makes sense however I would have expected the ModelForm to give an error indicating that the foreign key is blank (when it should not be) instead of adding it to the exclusion list meaning that it never gets updated when you call save. On Wednesday, 26 August 2015 19:43:16 UTC+8, Florian

Re: ForeignKey Fields null=True does not imply blank=True

It just occurred to me where I went wrong. I have a line that makes the form field non-required which means the form won't flag the validation error. Thanks Florian On Wednesday, 26 August 2015 20:18:48 UTC+8, khoobks wrote: > > That makes sense however I would have expected the ModelForm to

Re: ForeignKey Fields null=True does not imply blank=True

On 26 Aug 2:59, khoobks wrote: > Hi All, Hello! > To me, this seems like an unnecessary trap for users of the Django > Framework. However there may be a design decision here and I'd love to be > educated on why there would be a situation where it makes sense for > null=True and blank=False.

Re: Turn off migrations completely in Django 1.7

Hi Grzegorz, > On Aug 26, 2015, at 2:25 AM, Grzegorz Stalmierski > wrote: > > W dniu 25.08.2015 o 19:04, Marcin Nowak pisze: >> >> I would like to provide solid patch as a pull request, but I'm afraid that >> it will be rejected due to some kind of spirit, politics or something else. >> >>

Re: Turn off migrations completely in Django 1.7

On 08/26/2015 08:15 AM, Carl Meyer wrote: > I agree, and I already suggested a new feature (`managed=False` at the > AppConfig level) for which I think a solid patch would most likely be > accepted. This new feature would be capable of handling the "don't > migrate anything" case as well as the wid

Re: Turn off migrations completely in Django 1.7

2015-08-26 16:15 GMT+02:00 Carl Meyer : > You quoted me out of context. ​I'm sorry. It was unintentional. ​ -- ​Regards, ​Greg Stalmierski.​ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving em

Re: Turn off migrations completely in Django 1.7

On 26 August 2015 at 16:50, Carl Meyer wrote: > At this point the discussion belongs on the django-developers list, to > enumerate the real-world use cases and sort out the pros and cons of the > various possibilities. Getting a change into Django is rarely > impossible, but it does require commi

Re: Django 1.7 migrations: Adding one field to User`s model

Thanks, Hugo. My project already contains migrations. I've added migration with RunSQL. Monkey patch is detected for "django.contrib.auth" app, and Django tries to add migration in python egg (Django). I'm avoiding calling "makemigrations" without args (or "auth" as an argument). This is a D

Re: Django 1.7 migrations: Adding one field to User`s model

On Wed, Aug 26, 2015, at 15:02, marcin.j.no...@gmail.com wrote: > Thanks, Hugo. > > My project already contains migrations. I've added migration with > RunSQL. Monkey patch is detected for "django.contrib.auth" app, and > Django tries to add migration in python egg (Django). I'm avoiding > calling

Re: Django 1.7 migrations: Adding one field to User`s model

On 26 August 2015 at 20:09, Hugo Osvaldo Barrera wrote: > Oh, so the field you're adding in monkey patching contrib.auth.User? > IMHO, the design problem isn't django, but rather monkey-patching models > itself. Maybe you'd be better of using a custom user model. > I've tried to use custom user

Re: Django 1.7 migrations: Adding one field to User`s model

On 08/26/2015 12:18 PM, Marcin Nowak wrote: > > On 26 August 2015 at 20:09, Hugo Osvaldo Barrera > wrote: > > Oh, so the field you're adding in monkey patching contrib.auth.User? > IMHO, the design problem isn't django, but rather monkey-patching > models itse

Re: Django 1.7 migrations: Adding one field to User`s model

On Wednesday, August 26, 2015 at 8:23:01 PM UTC+2, Carl Meyer wrote: > > > I think that for this use case "Custom user" will not work. I was wrong. > > I must forget about "Custom user". ;) > > Yes. I think the most important Django limitation here is how difficult > it is to switch from built