Re: default values on database level

W dniu czwartek, 29 marca 2018 19:28:39 UTC+2 użytkownik Michael Grijalva napisał: > > Yeah seems like `db_default` was the felling, at least last time I scanned > through this long-going discussion :D > > I've had to tweak Django's migration handling a bit to handle our > zero-downtime

Re: default values on database level

Yeah seems like `db_default` was the felling, at least last time I scanned through this long-going discussion :D I've had to tweak Django's migration handling a bit to handle our zero-downtime requirements. SQLalchemy has had this for awhile

Re: default values on database level

Closing the loop here -- Tim just reopened https://code.djangoproject.com/ticket/470. This feature would also be useful for achieving zero-downtime migrations, as discussed in https://code.djangoproject.com/ticket/29266. Sounds like the design has mostly been agreed -- would a PR be accepted

Re: default values on database level

Hi everybody, Waking this up again because, going over some older stuff, I found a ticket asking for this feature: https://code.djangoproject.com/ticket/470 It was closed wontfix, but if anybody likes to put a 3-digit-numbered Django bug under their belt, it's there. The discussion in this

Re: default values on database level

Hi Owais, I did not have the time to start any work on this. I'm very much interested in this and I'd be happy to contribute to this in any way. I'm following along on the other thread you started [1]. [1]

Re: default values on database level

Hi all, I've a working PR that implements this but in a much inferior way https://github.com/django/django/pull/5904 I'm very interested in this and would love to contribute. Has anyone started work on this? If not, I'd like to pick it up. -- Owais On Tuesday, August 4, 2015 at 12:05:33 AM

Re: default values on database level

On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron wrote: > > > - Do we want to allow extending this to defaults that are applied on > every save (automatic database backed modified timestamps for example)? > > +1 for this one too. > This behavior would be a nice step

Re: default values on database level

On Aug 3, 2015 3:36 AM, "Anssi Kääriäinen" wrote: > > On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote: >> >> I would like to propose making Fields.default to rely on the database generated defaults where possible. This could be implemented by having some

Re: default values on database level

On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote: > > I would like to propose making Fields.default to rely on the database > generated defaults where possible. This could be implemented by having > some constants like fields.CURRENT_TIMESTAMP, etc. The tricky part here >

Re: default values on database level

indeed that's it. On Wed, Jul 29, 2015 at 12:23 PM, Loïc Bistuer wrote: > You could already achieve that by making MyPostgresqlFunction a subclass > of models.Func, I don't think it's worth supporting alternate syntaxes. > > Cheers, > Loïc > > > On Jul 29, 2015, at

Re: default values on database level

You could already achieve that by making MyPostgresqlFunction a subclass of models.Func, I don't think it's worth supporting alternate syntaxes. Cheers, Loïc > On Jul 29, 2015, at 23:05, Podrigal, Aron wrote: > > What about db_default allows either a constent eg. >

Re: default values on database level

What about db_default allows either a constent eg. db_default= contrib.postgres.functions. or a string "MyCustomPostgresFunction()" and optionaly allowing arguments to be passed to the db function optionally also allowing F() expressions by giving a tuple db_default=('MyPostgresqlFunction()',

Re: default values on database level

OK, that makes implementation a lot easier. As the model validation can be done with Model.check() based on the backend given at that time either when running the server or makmigrations. On Wed, Jul 29, 2015 at 11:50 AM, Michael Manfre wrote: > > > On Wed, Jul 29, 2015 at

Re: default values on database level

My main problem with "defaults in the database" was that the current "default" kwarg is too expressive for things we can put into a database and doesn't allow representation of "NOW()", etc. I'd be happy with a default_db arg with defined semantics and that would just blow up if you tried to pass

Re: default values on database level

On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron wrote: > Hi Loic, > > Agree with having a db_default kwarg. > > I am not using multiple databases so no experiance with db routers. So how > would should we handle routing between different databases when the > db_default

Re: default values on database level

Debatably this situation should throw an error at model validation time - assuming the expression does error out when trying to build that database. Otherwise it will error at migrate time. I would like this - it would be very good for UUID as PK On 29 July 2015 at 16:42, Podrigal, Aron

Re: default values on database level

Hi Loic, Agree with having a db_default kwarg. I am not using multiple databases so no experiance with db routers. So how would should we handle routing between different databases when the db_default value is not compatible with that backend? for example Model.save(using='mysql_db') should we

Re: default values on database level

On 07/28/2015 11:55 PM, Loïc Bistuer wrote: > +1 on db defaults as well, I've actually started experimenting on > this last week. It's a bit tricky because migrations do use db > defaults in some operations (and drop them once they are done) so we > have to ensure that the new feature doesn't

Re: default values on database level

Hi Aron, +1 on db defaults as well, I've actually started experimenting on this last week. It's a bit tricky because migrations do use db defaults in some operations (and drop them once they are done) so we have to ensure that the new feature doesn't interfere with them. However I don't think