GNOME Bugzilla – Bug 562147
Do not allow tables to have no primary key (use combobox)
Last modified: 2008-11-25 16:28:23 UTC
It is currently possible to delete the primary key from a table. But the rest of Glom (understandably) requires a primary key, so no data can then be shown for the table. We need to ensure that each table has a primary key so that the user does not get into that strange situation. For now, we might warn the user when closing the Field Definitions dialog. To properly fix this we need something more. We should probably not show the primary-key property as a checkbox column. We should probably make it a separate combobox that can never be empty, and not allow the user to delete a field if it is selected in that combo box. That would force the user to choose the other field before deleting the first one, which would force him to make sure that the field can be a primary key - for instance making sure that it does not have duplicate or null values.
Actually, I solved this without a combo box by just not allowing unsetting of the checkbox and _changing_ the key when setting, with appropriate confirmation and checks, with this commit: 2008-11-25 Murray Cumming <murrayc@murrayc.com> * glom/libglom/utils.[h|cc]: Added a show_ok_dialog() overload that takes the parent_window as a pointer to simplify code by avoiding the need for a null check by callers. * glom/mode_design/fields/box_db_table_definition.cc: check_field_change(): Refuse to leave no primary key set because the rest of Glom expects each table to have one, by refusing to directly unset a primary key. When setting a primary key, ask the user if they really want to _change_ the primary key, and do the suitability checks that were previously in change_definition(). change_definition(): When setting a primary key, unset the previous primary key first. This prevents the table from ever having no primary key. Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/glom/+bug/299549 (elmergato) Glom bug #562147