Allow classes to specify default values for fields

[ahti]

I think it would be nice to have a declarative way to give default values for not null columns.

As far as I can see, the best way right now is to override -didInit, and set default values if .existsInDatabase == NO.

Imho, it would be nicer if classes could implement a method like +defaultValueForFieldName: that takes precedence over the fieldInfos defaultValue (basically another else-if here).

That would even allow classes to set not null properties to nil temporarily, circumventing the default values.

If you would be willing to merge something like this, let me know and i'll whip up a pull request.

[LukeDurrant]

Seems simpler to just do it on the table level ie

integer NOT NULL DEFAULT 0

[marcoarment]

I think it's best to leave the defaults system as-is: reading from the table definition into the fieldinfo defaultValue. Having two very different mechanisms to do the same thing, yielding potentially conflicting values, doesn't feel like a good idea.

Even the existing defaultValue mechanism is a little questionable since normal Obj-C objects start with everything set to nil/0, and FCModels can differ from that. But that felt like a worthwhile inconsistency to introduce since it matched the database's behavior.

[ahti]

The problem I see with the existing mechanism is that it can't represent even mildly complex defaults like having a NSDate property default to the current date.

Instead, the default for a non-null date column is some fixed date, in most cases 1970-01-01 00:00:00 +0000, which I don't think is what many people want.

The two mechanisms could even be unified to some extent by making +[FCModel defaultValueForFieldName:] return the defaultValue of the corresponding fieldInfo, and subclasses can call super for fields where they want the default behaviour, so the way conflicts are resolved is very obvious and completely controlled by the user.

[marcoarment]

This seems to make sense primarily (only?) for setting usable defaults to NOT NULL non-numeric properties. But this is itself a weird idea in Cocoa.

Consider how it's done in a regular NSObject: everything's nil/0 by default, and if you want to change that, you set those values in an init method. Simple, established, standard.

Since FCModels shouldn't override init and we provide didInit for that purpose, I think your initial idea of overriding didInit is the right call for this — it's much simpler than the arbitrary-defaults system you're suggesting, and it has no major downsides.