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 > <javascript:>> 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. For more options, visit https://groups.google.com/d/optout.
