Hi Sam, That was also my idea for some time during development; I'm open to the idea, though it does mean bringing database defaults into Django as an overall concept, with all that that entails (e.g. documenting which default takes precedence; dealing with database-specific defaults; how to represent SQL functions; etc.).
If you're interested in whipping up a rough proposal, though, I'd be happy to look over it - people have been asking for this since migrations came around (and long before, too), as while Django never needs DB defaults anything else using the database does (plus some concurrency issues with default functions can be solved by moving them to the DB layer). Andrew On Sun, Apr 26, 2015 at 1:09 PM, Sam Baron <samba...@ownmail.net> wrote: > Greetings, I know this is an old thread, but it's an issue I am coming up > against and hopefully I can restart the conversation. I do think it's > important that we use as many native database features as possible for > application portability, extensibility, and performance. > > I have a different solution to the database default problem. Why not > handle it like SQLAlchemy? There are two field properties for default - > one applied at model instance (current Django default behavior) and one > sent to the database. In SQLAlchemy, it's called 'server_default', but for > Django, I think 'db_default' would be a more appropriate name. > > So for example: > integer_column = models.IntegerField(default=0) > OR > integer_column = models.IntegerField(db_default="0") > > And I agree that callables would not be included in 'db_default'. This > new property would only be for pushing SQL. With this solution, I think > you avoid user errors by keeping the two defaults behavior separate. Only > the advanced database folks will end up using it. > > I have made the relatively minor code changes on my end. I am in the > process and starting a new project and will keep testing it out. I am > curious if this would be an acceptable solution. > > Thanks, > Sam > > > On Saturday, November 1, 2014 at 10:17:50 AM UTC-7, Shai Berger wrote: >> >> On Friday 31 October 2014 19:16:15 Jon Dufresne wrote: >> > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin <and...@aeracode.org> >> wrote: >> > > So, bear in mind that you can easily set these defaults yourself in a >> > > migration with RunSQL if you need them for legacy purposes; that way >> > > they'll get applied >> > >> > Absolutely. I effectively have such a system in place at the moment. >> > >> > But, my point is I am also making an effort to match Django's expected >> > schema while moving away from the legacy schema. I would prefer not to >> > drift too far from Django's expectations as the goal is move entirely >> > to Django. This is just one more thing to keep track of and handle >> > semi-manually. >> > >> > All I'm saying is that if the described feature existed, it would >> > benefit me and others that share my use case. >> >> So, we should be weighing the support-transition-from-legacy use-case >> against >> creating a situation where field defaults get a special treatment if they >> are >> primitive enough (callables are out, but I am really not sure about other >> complex objects -- GIS would probably gain a new dimension of fun if it >> were >> to deal with defaults, even when not callable). >> >> I think the correct way forward for migrations is to keep as it does >> today -- >> requiring users to explicitly ask for db defaults (we could, as I said >> earlier, give it a nicer API than RunSQL). >> >> As for "Django's expectations" -- while I don't think we should generate >> db >> defaults unless specifically asked to, I don't see where such defaults >> could >> get in our way. If you ever run into a situation where Django mishandles >> some >> table because it has defaults, that is almost for sure a bug. >> >> My 2 cents, >> 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/e7d99cf6-c6a5-4d32-994c-7dd4e07ad478%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/e7d99cf6-c6a5-4d32-994c-7dd4e07ad478%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1urNBh2Y9Qf6k37h7NoA59e%2BRJqLHT4N562mB457kiLinw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
