hello,how can I set the default value of a column in the migration called due_on with type datetime to n days from now at the time when a model is created ?
Your migration will have to include a block of code where you go set those values yourself for those records where due_on is null (which would be all of them if this is a new field). -- Posted via http://www.ruby-forum.com/.
After the migration, that sort of logic belongs in your model code, in an after create callback. -- Posted via http://www.ruby-forum.com/.
Thanks Ar Chron, - one question: why after create is chosen over before create in supplying the date that''s n days from now? Could it be that this is for validation concerns? On Aug 14, 9:48 am, Ar Chron <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> After the migration, that sort of logic belongs in your model code, in > an after create callback. > -- > Posted viahttp://www.ruby-forum.com/.
In retrospect, before_create should be fine as it occurs right before Base.save if I recall correctly. But I would choose a callback which occurs after the validations to default a value for a new record, unless some validation depends on that data. It can get pretty messy with the timings, depending on how your models are related. -- Posted via http://www.ruby-forum.com/.
Sorry I was out of internet for a few days. -- I see, so this is so that some sort of predetermined/ non-empty date will always be supplied in a business logic point of view. On Aug 14, 4:38 pm, Ar Chron <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> In retrospect, before_create should be fine as it occurs right before > Base.save if I recall correctly. > > But I would choose a callback which occurs after the validations to > default a value for a new record, unless some validation depends on that > data. It can get pretty messy with the timings, depending on how your > models are related. > -- > Posted viahttp://www.ruby-forum.com/.