#21 automation_id: DEFAULT for foreign_key

[Donald Organ]

I would suggest that we create something to give us the ability to assign a default VALUE for a foreign_key only if one of the values is defined in content that is defined in the YAML. This way you can be sure it will exists and wont though any errors.

An example of this would be order status

order status can be the following:
New Order
Order Processing
In Production
Shipped
Invoiced

You would want to define the default as "New Order"
so I guess what we could do is:

use the automation_id: DEFAULT in the column in the table so define the foreign_key then define the column the foreign_key is bring in and assign the automation_id as usual and have the builder check for foreign_key status if yes check for content and default value.

[Kenneth Downs]

Logged In: YES
user_id=1711200
Originator: NO

If I understand your suggestion, then we have this now. You can specify a foreign key, then specify the columns you know will be created and hardcode a default value.

Now, wouldn't it be better if we put a "default" flag on rows in the parent table, and used a trick similar to DOMINANT to make sure only one was set, so that end-users could determine the defaults?

Or better yet, do we need a general system for allowing users to specify defaults, of which this would be one instance? Personally I suspect we do NOT need a generalized system only because I have not seen an example yet.

[Donald Organ]

Logged In: YES
user_id=1268217
Originator: YES

What if you want to reference this table from multiple tables, and want a different default for each??

[Kenneth Downs]

Logged In: YES
user_id=1711200
Originator: NO

I don't know. There is always the fallback to hardcoding defaults in yaml, which we can do now.

[Kenneth Downs]

Maybe drive this off the DOMINANT flag? Grab values from the DOMINANT row in the parent table? Kind of the opposite of the FETCHDOM we have now.