Hi Shai,
El martes, 25 de abril de 2017, 18:28:57 (UTC-3), Shai Berger escribió: > > Hi Maxi, > > On Tuesday 25 April 2017 20:21:47 Maximiliano Robaina wrote: > > Hi, > > > > Sorry but a need to return to this > > > > El jueves, 20 de octubre de 2016, 9:53:23 (UTC-3), Tim Graham escribió: > > > The 'default' model field option is used in Python rather than in the > > > database. SchemaEditor might set a column default to ease populating a > > > value on existing rows but that default shouldn't be left in the > column's > > > definition. self.assertIsNone(field.default) means that the column > > > doesn't have a default. > > > > Ok, you say that SchemaEditor set a column default to ease populating a > > value on existing row. Which sql engine works in that way? > > All of them, as far as I know. > > > I was reading into postgresql docs [1] and it says that add a column > > default definition "Note that this doesn't affect any existing rows in > the > > table, it just changes the default for future INSERT commands.". So, I > > don't undertend why add a database default definition is useful if later > we > > need to remove it. > > > > That statement is correct if it refers to adding a default definition to > an > existing column, but SchemaEditor uses defaults only when it adds new > columns. > if you add a new column to a table that already has rows, then the easiest > way > to set a value for all existing rows is to define it as default. If the > column > is not nullable, you actually cannot add it without a default. > > And yet, some Python defaults cannot be represented in SQL (mostly > functions), > and we'd much rather use Python defaults. Experience (in South) has shown > that > defaults in the database, when used carelessly, cause problems, so we try > to > keep them out. > Yes, I understand that and I agree. I my case, Firebird has an strange behavior when you add a new not null field with a default and then remove the default definition. I must to implement other strategies. Regards Maxi > > HTH, > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c7f2d7d3-a540-486e-9e61-cf89e3911abf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.