Enhancement: Default Values on addColumn

[SattaiLanfear]

When creating a new column with addColumn in a migration, if the column isn't meant to be nullable you frequently need to provide a default value for it.

One way to do that is to immediately follow with a bulk update statement, but this seems clumsy and as soon as you do that you're forced to introduce a customScript block.

It seems adding a defaulted "default" value to the column creation method might simplify things greatly (as well as improve reliability).

eg:

table[Foo].addColumn(_.column[String]("bar", default = Some("BAR")))
table[Foo].addColumn(
  _.customColumn[String]("bar2", "json", default = Some("{}")))
table[Foo].addColumn(_.column[String]("nullableBarWithoutDefault"))

default can then default to None to maintain the current behavior.

[fwbrasil]

From the Activate perspective, the database should behave as a simple storage. It should be capable to recover the same contents stored previously, or else some guarantees provided by Activate can't be ensured. The default column value breaks the store/recover symmetry.

I'm closing the issue for now, please reopen if necessary.

[frossi85]

It is not the same case, but when you add a new column of type List, perhaps will be helpful to automatically initialize it with Nil. The same for Option initialized with None. In this way, we can avoid Null reference problem and initialize the property to a reasonable value. Is this convention breaking the Activate perspective??

Regards

Facundo

[fwbrasil]

For Options, null is already mapped to None. For lists, I think the current behavior is consistent, since they have the same behavior as other types. After create a new column, an additional script to fill the new column is enough.