constraints do not work in table "form view" or "table view"

[qgib]

Author Name: Giovanni Manghi (@gioman) Original Redmine Issue: 21906 Affected QGIS version: 3.6.2 Redmine category:vectors

---

Constraints seem to work when updating the attributes using the feature form that opens using the identify tool, but hey do not work in the table of attributes both in "table view" or "form view" (at least in "form view" is very unexpected to not work).

[qgib]

Author Name: Matthias Kuhn (@m-kuhn)

---

Do you have a proposal for expected behavior?

Should values just not be accepted and silently discarded or some feedback given and if yes, where and how.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Hi Matthias, thanks for the feedback

Matthias Kuhn wrote:

Do you have a proposal for expected behavior?

Should values just not be accepted and silently discarded or some feedback given and if yes, where and how.

well, I don't know what is possible to do in "table view" in terms of enforcing the constraints and show messages, if the answer is "nothing easy" then imho I would definitely block the save operation.

the "form view" is another thing: I can't see (of course I'm not a dev, so I may be wrong) why this form should not work as the form that pop-ups when identifying a feature, where the constraints work as expected. If possible I would make the "form view" work exactly as the "identify forms" (not sure it is the right name).

[gioman]

Months are passing, very cool new feature are being added all the time (thanks to anyone that makes them possible), but I still can't understand how an issue like this one does not get any traction. I just checked on master and still in the table of attributes is possible to enter and save values that openly in disagreement with the configured constraints. Isn't anyone else concerned other than me that this way we are allowing user to enter wrong data in their tables?

[haubourg]

Well, to reword things, soft constraints (orange warnings) are working correcty, but enforced constraint do not apply as long as there is no OK button to validate a form. To have this, we would need to raise an error message bar when users try to switch to another feature (which throws the UPDATE live in transaction mode). That is potentially a big task dealing with signals / slots to handle all use cases correctly.
In most cases I deal with, users are focused on standalone forms. In the cases they would uses the form view, they already have the soft warnings raising, and we enforce those constraints on the database side, so they get warnings when commiting (live with transaction group or on save with classical edit mode). I think most users face more important issues and find workarounds here, maybe it's why it didn't get more traction on user's side. And the developper solution is not that easy as points @m-kuhn

[gioman]

@haubourg Hi Regis,

Well, to reword things, soft constraints (orange warnings) are working correcty, but enforced constraint do not apply as long as there is no OK button to validate a form.

Unfortunately is not true: the "hard constraint" (i.e. "enforce not null constraint") is completely ignored when saving a feature from the "form view" of the table of attributes. It only works from within the form when finishing digitizing a new feature or identifying a feature.

Moreover from within the "table view" there isn't anything at all (not even the "soft constraint" warning) that warn the user about the constraints.

As said above I can't see a reason why the "hard" constraints are working in the form when inserting a feature or identifying one and not in the form view of the table of attributes.

If implementing the constraints in the table view is too hard then editing in table view should be completely disabled in case of having even a single constraint configured.

To have this, we would need to raise an error message bar when users try to switch to another feature (which throws the UPDATE live in transaction mode). That is potentially a big task dealing with signals / slots to handle all use cases correctly.

not sure I follow this.

In most cases I deal with, users are focused on standalone forms. In the cases they would uses the form view, they already have the soft warnings raising, and we enforce those constraints on the database side, so they get warnings when commiting (live with transaction group or on save with classical edit mode).

most of users still not use a database and the still edit attributes from within the table.

So to the vast majority of users we give them a tool that give the impression that they can "lock down" data entry in their vectors but then this tool is half broken (or half implemented, as you prefer) and someone could not even realize it (with possible very bad consequences).

I add also that we frequently make a point of having QGIS behave like a real database: for example the "not null" constraint does not work (rightly) when the field is just empty (but for the vast majority is users null is equal to empty, so we should really also add a constraint for "not empty"), but in a real database a configured constraint work always, not only when using some specific tool to entry/edit the data. In this sense we are really inconsistent.

I think most users face more important issues and find workarounds here, maybe it's why it didn't get more traction on user's side.

actually when I wrote "traction" I was thinking to the QGIS project not the users. To me this a huge issue. I have shown this issue to a few (quite a lot) users and they were pretty much all shocked about it.

[nyalldawson]

If implementing the constraints in the table view is too hard then editing in table view should be completely disabled in case of having even a single constraint configured.

This sounds reasonable to me!

[m-kuhn]

I tried once to implement this in the form view of the attribute table and gave up because it was not trivial. I think it should be possible but will require a fair amount of work.

If implementing the constraints in the table view is too hard then editing in table view should be completely disabled in case of having even a single constraint configured.

This sounds reasonable to me!

No more editing in the attribute table? No more multi edit? I'm not sure we will make users happier with that ...

I'm sure we have other tools do that can introduce constraint issues. It's a long road to go to tackle every possible entry point for constraint issues. And to do that properly it will need to be implemented on a different (provider) level than the one (layer) it currently is. I remember having written that "QGIS is not a database system" somewhere a long time ago (maybe regarding relations?). I think this should be stressed more prominently in the docs and trainings.

[gioman]

Hi Matthias,

I tried once to implement this in the form view of the attribute table and gave up because it was not trivial. I think it should be possible but will require a fair amount of work.

that's unfortunate, it is "only" the "hard" constraint that do not work ("enforce..."). Anyway this is very (very) confusing for users as the form view in the map work as expected.

No more editing in the attribute table? No more multi edit? I'm not sure we will make users happier with that ...

isn't multiedit a thing of only the form view of the table of attributes? The proposal here is to block the edits in table view only, and only if there is a constraint (even a single). Eventually another solution would be to add a check in table view that says "enable editing, do it at your risk, constraints nor supported in table view".

I'm sure we have other tools do that can introduce constraint issues. It's a long road to go to tackle every possible entry point for constraint issues.

maybe, but it's also a matter of fixing firstly (and urgently) the most used entry points. What is the proportion of "table of attributes VS others"? I would say overwhelmingly shifted to the left...

And to do that properly it will need to be implemented on a different (provider) level than the one (layer) it currently is.

that is unfortunate again: the idea of allow the user mimic db constraints regardless of the datasource (so even for shapefiles) is a fantastic one, does we need to take away this in the future?

I remember having written that "QGIS is not a database system" somewhere a long time ago (maybe regarding relations?). I think this should be stressed more prominently in the docs and trainings.

I think that it's a bit unfair for users to ask them think to QGIS as database in some occasion (i.e. expressions, NULL vs empty, etc.) and not as a db in others. I think is right to make QGIS behave as a db, but we must be consistent how this approach work within the whole application, not only in some part.

[m-kuhn]

maybe, but it's also a matter of fixing firstly (and urgently) the most used entry points. What is the proportion of "table of attributes VS others"? I would say overwhelmingly shifted to the left...

Sorry, I was extrapolating from the title which says "form view" or "table view". I was afraid of this request suddenly affecting many tools. My bad.

If it's just the attribute table, I can live with it. But even here I have my reservations if it does more good (by preventing inconsistent data) or bad (by preventing people to work in a natural way).

---

In my defense: I am very much in favour of seeing QGIS acting like a database where possible (that's why I introduced all those tools actually). What I'm worried about is feasibility, complexity, performance and usability impacts. There's a lot to balance here. Please take this as an excuse if I sometimes complicate things when behaviour changes in this area are requested. When I introduced those tools I meant them to help people to enter data (giving them hints) and not to restrict them in what they can do with this application.

[py-qgis-user]

I must admit I was really surprised when I encountered that the constraints are not enforced in the attribute table. In the table view it doesn't even hint that the entry is invalid. For this I would like to add two things to the discussion:

1) I'm hopeful somebody will find the time to implement enforced constraints. It is very useful to many users. Hence this post to refresh memory of the issue 2) At first I was pro the quote below, or wanted to propose to add a checkbox in the layer's form attributes to disable the attribute table to enforce the constraints. Yet later I realized that this might fully block editing of tables (not linked to geometry locations, so the pop-up form is not accessible), which is definitely not preferable.

If implementing the constraints in the table view is too hard then editing in table view should be completely disabled in case of having even a single constraint configured.

This sounds reasonable to me!

[gioman]

1. It is very useful to many users

it is not only useful, it a source of errors (you think you have constraint, but then is completely ignored).

2\. ully block editing of tables (not linked to geometry locations, so the pop-up form is not accessible)

I think that form view is always available also for geometryless tables.

[MrChebur]

Spent a lot of time testing and found that constraints don't work in attribute tables. https://gis.stackexchange.com/q/414483/35561

At least we need some message about that issue in the UI.

[gioman]

Spent a lot of time testing and found that constraints don't work in attribute tables.

@MrChebur yep... I'm still very vocal about this matter. To me should be:

if having a constraint (even just one)

1) disable editing in table view (because it seems very hard to implement constraints in table view), with a very clear message explaining why

2) makes constraints work in form view from within the table of attributes. As they works in form view when adding a feature or when identifying a feature, there is really no reason why they should not work when opening a form from the table of attributes

3) warn the users about constraints when using tools like the multi-edit (i.e. "warning, this tool will override any constraint")

4) along the way please.... add a "not empty" constraint (in opposition to the existing "not null").