GNOME Bugzilla – Bug 771132
Combo update failure in SimpleUIForm example and gdaui-demo-5.0 'Same Data'. Specific source code issue identified
Last modified: 2018-09-21 13:56:45 UTC
A few clicks of next button for the SimpleUIForm example and the 'Same Data' demo of gdaui-demo-5.0 shows combo updates are not occurring. What is interesting and misleading is that initial investigations suggest there has been incorrect plumbing that reverses a correct update by updating a second time from stale ui data. Further investigation shows there was a failed attempt made to update ui data. Following is output from the SimpleUIForm example (example-ro or example-rw) with DEBUG_HOLDER left defined in gda-holder.c If reproducing this report please note I changed the SalesTest customer table to ensure no customer has NULL as a salesrep as NULL adds complications that are not needed for the purpose of investigation. Three 'next' click results in: Holder to change 0x7bb860 (id): value 2 --> 9 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Ed Lamton --> Greg Popoff (type 64 -> 64) VALID: 1->1 CHANGED: 2 Holder to change 0x7bba00 (default_served_by): value 1 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bba00 (default_served_by): value 4 --> 1 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb860 (id): value 9 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Greg Popoff --> Lew Bonito (type 64 -> 64) VALID: 1->1 CHANGED: 5 Holder to change 0x7bba00 (default_served_by): value 1 --> 2 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bba00 (default_served_by): value 2 --> 1 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb860 (id): value 3 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Lew Bonito --> Mark Lawrence (type 64 -> 64) VALID: 1->1 CHANGED: 1 Holder to change 0x7bba00 (default_served_by): value 1 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bba00 (default_served_by): value 3 --> 1 (type 24 -> 24) VALID: 1->1 CHANGED: 1 For each click the fourth holder change is both redundant and incorrect. The fourth line is a result of signal callback to 'gdaui_basic_form_set_as_reference' as a result of g_object_set (G_OBJECT (iter), "current-row", row, "update-model", update_model, NULL); in function 'gda_data_model_iter_move_to_row_default' However this is not necessarily relevant as the fourth line update would not have occurred if the holder value was already correct. So I continued my investigation deeper into the pit. Was appears more relevant is that stepping through every call made to 'gdaui_data_store_get_iter_from_values' of gdaui-data-store.c from line 508 in gdaui-entry-combo.c if (gdaui_data_store_get_iter_from_values (GDAUI_DATA_STORE (model), &iter, values, gdaui_set_source_get_ref_columns (combo->priv->source))) { always resulted in a FALSE return There is a workaround but it is not satisfactory. The workaround bypasses the update failure by blitzing in correct values. Below gda_holder_set_source_model (holder, salesrep, 0, NULL); I added in: g_signal_connect(holder, "changed", G_CALLBACK (sync_form), salesrep); and used the following callback: static void sync_form(GdaHolder *holder, GdaDataModel *model) { g_signal_emit_by_name (holder, "source-changed", 0); } Following are results with workaround of three next clicks: Holder to change 0x7bb860 (id): value 2 --> 9 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Ed Lamton --> Greg Popoff (type 64 -> 64) VALID: 1->1 CHANGED: 2 Holder to change 0x7bba00 (default_served_by): value 1 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb860 (id): value 9 --> 9 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bb9a0 (name): value Greg Popoff --> Greg Popoff (type 64 -> 64) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 4 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 4 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 4 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bb860 (id): value 9 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Greg Popoff --> Lew Bonito (type 64 -> 64) VALID: 1->1 CHANGED: 5 Holder to change 0x7bba00 (default_served_by): value 4 --> 2 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb860 (id): value 3 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bb9a0 (name): value Lew Bonito --> Lew Bonito (type 64 -> 64) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 2 --> 2 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 2 --> 2 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 2 --> 2 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bb860 (id): value 3 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb9a0 (name): value Lew Bonito --> Mark Lawrence (type 64 -> 64) VALID: 1->1 CHANGED: 1 Holder to change 0x7bba00 (default_served_by): value 2 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 1 Holder to change 0x7bb860 (id): value 4 --> 4 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bb9a0 (name): value Mark Lawrence --> Mark Lawrence (type 64 -> 64) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 3 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 3 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 0 Holder to change 0x7bba00 (default_served_by): value 3 --> 3 (type 24 -> 24) VALID: 1->1 CHANGED: 0
I continued working on this bug and am pleased to have found it and its fix. The bug was nasty to find find so if anyone else is working on finding this bug as a result of this report you can relax. I have tested the fix with both libgda-6.0 (current master branch) and libgda-5.0 (current LIBGDA_5.2 branch). Both worked as expected with the fix. I will fork these repos from GitHub and make pull requests. I would very much appreciate if the pull requests are accepted so I can get formally credited as a contributor. I would understand if there was reluctance to credit me as a contributor for just a one line bug fix. But please remember it took considerable effort to find the bug, I persisted when I doubted I would be able to find the bug, the bug is long standing and the bug severely disabled some incredibly useful features of libgda. John Heenan
Created attachment 341395 [details] [review] Fix for libgda combo update failure: cols_index A few clicks of next button for the SimpleUIForm example and the 'Same Data' demo of gdaui-demo shows combo updates are not occurring. The problem occurs in both libgda-6.0 (libgda master branch) and libgda-5.0 (LIBGDA_5.2 branch). The problem is more obvious if the sample database table (SalesTest) is edited to ensure no customers have NULL as a salesrep. Tests showed the problem is fixed in both branches by editing a single line in function gdaui_set_source_get_ref_columns to return the ref_cols_index instead of the shown_cols_index.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgda/issues/123.