Allow :id, :created_at, :updated_at to be cast? about plsm HOT 7 CLOSED

I think that those who would possibly need that feature could go in and hand code the changes after they generate the models using plsm. That is an uncommon usage and it is better to have to add than to remove. That way for those who want to get going right away can and those who want more fine grain control or go against the norm will be able to continue to do that with a bit of tweaking on the result. Thoughts?

from plsm.

Or we could add a flag to the mix task to not have the columns be removed.

I was also thinking that if both created_at and updated_at existed, we could append timestamps to the schema as well.

from plsm.

Sorry but I'm not following you on your first sentence. Are you referring to having the columns removed from the cast or from the entire schema?

If we were to replace created_at and updated_at with timestamps then it is imperative that we also check the column type for those two columns and only replace the pair if both columns are datetimes. There will be issues if they are just date fields and we try to pass in a datetime.

from plsm.

Sorry, what I mean is that we could add an option to the mix task, so if the user wanted to keep the id/created_at/updated_at, they could do:
mix plsm --generate-ids
or something

I agree that we should check that the fields match though before removing it from the schema.

from plsm.

Ah ok, that makes sense. Would it make more sense to keep the options in the config? That way it is self documenting (when the config is generated it will generate a field with whatever default we chose) and it re-running the process simple (no need to remember flags). Honestly, I'm not sure if it is a "good" practice to have these types of things in config files instead of command line flags but that is where I'm leaning. Thoughts on that?

from plsm.

Either way is fine, honestly I don't see the config file being committed to version control anyway, and the config file is nice because as the repo grows you can just dump it into the config file.

Or we could convert it into a proper config (that lives in config.exs (or dev.exs/whatever).

from plsm.

This won't be implemented as it can be done by the user if need be.

from plsm.