NotBlank for Primary Key fields (for non Singleton tables)

[fvet]

In the past we often faced issues on master / referential data tables having a blank value as Primary Key value. When the user detected the blank value and performed a rename, suddenly all fields with a TableRelation to this parent table got - wrongfully - updated.

Since then, we apply a rule to ensure the Primary Key value of a table must be filled, by setting the NotBlank = true property on the PK field.

It would be nice if we could have a rule to check tables:

• With a single field Primary Key
• With a code field as Primary Key
• Test if the NotBlank property has been set

IMPORTANT : This rule will however conflict with the Singleton pattern and should thus exclude 'Setup' tables (without having to explicitly set a pragma):

• We could exclude fields named "Primary Key"
• We could exclude tables named "*Setup"
• We could exclude tables having no list page (only a card page)
• Other ideas?

[StefanMaron]

The setup table is indeed tricky. Maybe if the primay key field is not used on pages either? Or not used at all?

[fvet]

Since we lack a direct indication on table, I think it's best to use the underlying page definition to detect a 'Setup' table.

Setup tables can be identified as

• A table without list page

• A table with only a card page, having

  DeleteAllowed = false;
  InsertAllowed = false;
  

I think this is the closest we can come, following the standard BC setup pattern.

If only we would have a Table Subtype / Clasiffication property ... ;)

[StefanMaron]

Delete and insert allowed would need to be a check it self 🙈😅

[StefanMaron]

After thinking some time about this, I will not handle setup tables. There might be exclusions even for them.
The warning will show up also for Primary fields and the developer will be reminded to think about it.
if the field should not be NotBlank = true, a pragma can always be applied.

If we will have a clear rule for those kind of setup tables, I will change this check.

[StefanMaron]

This got released as new rule. #89

If you encounter any issues, please open an issue

[fvet]

@StefanMaron

Thinking a bit further about this rule, it does not apply for master data / documents adopting the 'No. Series' pattern. If you would set the NotBlank e.g. on the No. field in the Customer table, the insert will fail ...

... since the NotBlank is evaluated before the OnInsert trigger (containing fallback code to fetch the No. via No. Series)

This rule will result in a lot of false positives (adding a pragma on all of those seems a bit overkill ?) if you'd run it on the Base App.
Maybe we should still try to find a way to exclude tables having a 'No. Series' field? (Named "Nos. Series" or "No. Series")

[StefanMaron]

I think, a check for the No. Series field is the best way.
I would not go with the name but with the TableRelation = "No. Series";

[StefanMaron]

Done. Its now available to test in the current pre-release

[curateideas]

It's still giving false positives, I guess. The field can have no TableRelation, but is filled via No. Series logic (new implementation).

[StefanMaron]

Do you have an example of code that would make sense to add to the check for this rule? .