06-11-2020, 03:07 PM
Whenever there is a long list of errors, most of the time, it is the first error, not the last that matters. In your case, it is this:
WARNING: could not commit [config/widget_config?project=ramontest05_status&code=WIDGET_CONFIG000000] due to error [duplicate key value violates unique constraint "widget_config_code_idx"
DETAIL: Key (code)=(WIDGET_CONFIG000000) already exists.
For whatever reason, you have this code twice, either in your .spt files or there already exists an entry in the database. As a rule, for plugins, unless you explicitly name the code yourself to ensure it's uniqueness, you should never dump out the code. You can do this in the manifest with the "ignore_columns" attribute.
For example, we often do this:
<sobject search_type="config/widget_config" path="config/widget_config.spt" ignore_columns="id,code" unique="true"/>
Thus when you load the plugin, it will let TACTIC auto-assign the code. This will not matter for things like entries in the widget_config table unless the code is directly referenced by some other part in your code. In that case, you should explicitly name the code.
One other thing we do have in TACTIC code is to make codes randomly generated, ie: SNAPSHOTadfasfaefea (much like Github commits). This can be turned on individually for each search type and would ensure that there is never a conflict. We've never actually done this as a default, but I think there are some search types (such as widget config, snapshot, files) where this would be useful.
WARNING: could not commit [config/widget_config?project=ramontest05_status&code=WIDGET_CONFIG000000] due to error [duplicate key value violates unique constraint "widget_config_code_idx"
DETAIL: Key (code)=(WIDGET_CONFIG000000) already exists.
For whatever reason, you have this code twice, either in your .spt files or there already exists an entry in the database. As a rule, for plugins, unless you explicitly name the code yourself to ensure it's uniqueness, you should never dump out the code. You can do this in the manifest with the "ignore_columns" attribute.
For example, we often do this:
<sobject search_type="config/widget_config" path="config/widget_config.spt" ignore_columns="id,code" unique="true"/>
Thus when you load the plugin, it will let TACTIC auto-assign the code. This will not matter for things like entries in the widget_config table unless the code is directly referenced by some other part in your code. In that case, you should explicitly name the code.
One other thing we do have in TACTIC code is to make codes randomly generated, ie: SNAPSHOTadfasfaefea (much like Github commits). This can be turned on individually for each search type and would ensure that there is never a conflict. We've never actually done this as a default, but I think there are some search types (such as widget config, snapshot, files) where this would be useful.