Bug in handling unique field

[ppfoong]

Appgini 24.17

I purposely test saving the same data to a unique field.

A red line of text comes out under the field. It appears too fast that I can't read it.

Then, it goes back to the table view page.

An admin only message is displayed on top:
"Couldn't save the new record", followed by 2 lines of text explaining about the duplicate entry.

Now comes the bug:

The records displayed in the table, as well as the record count, is missing one record. The missing record is the one that I tried to duplicate.

Which means, now in the table, the original record disappeared.

Example, the table has:

Apple
Orange
Banana

If I try to save Apple again, now the table become:

Orange
Banana

(the Apple is gone)

When I check in MySQL database, the record is still there, which is correct. Just that in Appgini, it is disappeared throughout the session.

If I logout and login back, it will reappear.

So this bug does not affect the actual data in database, but it affects the record display in Appgini, until a logout and login is performed.

[zibrahim]

Hmmm...it is not happening to me....strange...

SCR-20240909-holr.png (48.22 KiB) Viewed 265 times

[ppfoong]

Hmm...

Maybe caused by AdminLTE for Appgini plugin...

[snawaz]

I've also noticed the unusual behavior. When I intentionally try to insert duplicate text in a unique field, the error does not appear until I click somewhere else on the page. If I try entering duplicate text and directly click on the save button, it shows the error but still saves the record in the database.

It seems the unique constraint is not being validated in real time, unlike primary keys. Since we cannot make multiple fields primary keys, we are using a unique constraint, but it is not functioning as expected.

Could anyone suggest how to resolve this issue?

[jsetzer]

Bug in handling unique field

I don't think it's a bug but a usability issue:

Validation takes place in onChange event, not in onInput event. In other words: not on every keystroke but on leaving the field.

In normal <input/> fields leaving the input field for example by pressing TAB key or by clicking somewhere else (so called blur-event) triggers the change event, if changed.

I agree it's sometimes confusing: you think you clicked the Save button but actually that click outside the <input/> (blur event) checks for changes, then triggers validation. If this fails, submitting the form will be prevented.

Confusing from usability point of view, but plausible from technical point of view. One of my customers also complained about this usability issue two years ago.

Triggering validation on every keystroke (instead of onBlur event) may lead to performance issues and more problems with other constraints.

So, considering pro and con, in current AppGini I think it's best to train the users to leave input fields using TAB key after changing values. Then everything is fine: validation will take place and save button may be disabled.

My customers are used to this now and understand the technical necessity.

Hope this helps.

[snawaz]

Dear jsetzer

I totally agree with your explanation, and I understand the behavior much better now. There’s no more confusion on my end. Thank you so much for clarifying and helping me understand the technical reasoning behind it.