GNOME Bugzilla – Bug 413258
Committing modified rows in GdaDataModelHash fails
Last modified: 2008-10-02 19:04:38 UTC
When making modifications to a GdaDataModelHash in (retrieved as a GdaSqliteRecordset from gda_connection_execute_select_command, for instance), say, a GnomeDbGrid, the user interface is not updated when committing the changes into the GdaDataModelHash. Also, the total number of rows stays always the same, even if rows are removed or inserted (some rows with empty values are displayed or some get discarded respectively). This seems only to be the case with the sqlite provider.
Created attachment 83599 [details] [review] Patch proposal I fixed this in GdaDataProxy by always calling adjust_displayed_chunk() at the end of commit_row_modif(). There are probably other possibilities to get it right, but I am not that confident with the libgda code and this seems to do the trick without breaking anything else. Are there any reasons (performance?) why the get_n_rows() implementation of GdaDataModelHash cannot be used GdaSqliteRecordset? After having commented out the get_n_rows override, a problem remains in gda_data_model_hash_clear(): After having replaced the hash table and acquired a new one, it calls get_n_rows to set the number of hash table rows. However, since the hash table has just been cleared, it should be obvious, that there are no rows in it (although the get_n_rows() call yields -1 because the row mapping area has been freed at that time). If I got it right from the code, this row mapping array maps numbers between 0 and the number of rows to the actual number used in the hash table to reference a row. gda_data_model_hash_clear() creates some mappings at the end (or rather, it would, if get_n_rows() would have returned something nonzero, as the sqlite-recordset get_n_rows implementation does), but the hash table itself stays empty (which is exactly what I would expect if I called gda_data_model_hash_clear).
Armin, if there is no reply in 3 days, please just commit.
Committed. I leave the bug open, so that we can perhaps find a better solution later.
Could you say what's maybe wrong with the code that's checked in? If there's nothing obviously wrong then please close this bug.
A correct/better approach is probably to implement i_get_attributes_at in the sqlite recordset datamodel (and also in others, in the long term). Compare to http://mail.gnome.org/archives/gnome-db-list/2007-March/msg00006.html.
This has been rendered obsolete with the new V4 implementation of the GdaDataSelect (the GdaDataModelHash object has been removed), so I'm closing this bug.