Re: [gnome-db] libgnomedb: data validation

["Vivien Malerba" <vmalerba gmail com>]

On 12/4/06, Murray Cumming <murrayc murrayc com> wrote:
> On Fri, 2006-12-01 at 10:37 +0100, Vivien Malerba wrote:
> > For numerical values, the individual cell renderers used in a grid, or
> > the data entry widgets used in a form will let you enter any
> > character, but the returned value is the same as if you used the
> > atoi() family functions.
> >
> > The current implementation does not let you do any specific formatting
> > nor any specific control. However there is only some code to add to
> > make this possible, there is no infrastructure to change, in fact this
> > is already done for the existing plugins within libgnomedb.
>
> I'm not sure what you mean by plugins here. Links to viewcvs might help
> me understand.

Plugins are shared library files which contain code which implements
one or more GnomeDbDataEntry widgets and/or one or more
GtkCellRenderer objects. Plugins also come with XML config files which
tells what options are available to each plugin.

Libgnomedb comes with default data entry widgets (in
libgnomedb/data-entries), and with some plugins (in
libgnomedb/data-entries/plugins). The extra/demos/form_pict.c file
contains an example of how to use a plugin).

> >  More
> > specifically, have a look at the gnome_db_util_new_cell_renderer() and
> > related functions in the gnome-db-tools.c file (for example for the
> > GnomeDbEntryPict plugin, which definition files are in
> > data-entries/plugins/).
> >
> > >
> > > How does the UI behave if the database server rejects the data?
> > >
> >
> > The problem is more generic than that, because a grid may display data
> > which is not related to something in a database. In fact the grid
> > widget just displays what's in its proxy (created on top of the
> > GdaDataModel which contains data to display). So the answer is that
> > the behaviour of the grid (or form for that matter) is the same as the
> > GdaDataProxy object.
>
> But this GdaDataProxy is not something that the application developer
> sees, right? I mean, it's not public API?

It's public API. You usually don't have to worry about it since its
usage is hidden in the implementation of the objects using it, but for
a "fine tuning" of some behaviours, you need to use it.

The best example is if you need to have a form and a grid display the
same data. If you just create a form and a grid with the same
GdaDataModel, then if you make some modification from the form
(without actually applying the modifications), then you won't see that
modification in the grid. If now you create a form, then get its proxy
and create a grid with that proxy, then any modification made in the
form will show in the grid (and vice versa of course).

> > Specifically to the situation you mention, the GdaDataModel to display
> > must be a GdaDataModelQuery object.
>
> Which is returned from gda_connection_execute_select_command(), right?

This method returns a read-only data set (unless some provider allow
it to be modifyable). If you want a read-write data set, then create a
GdaDataModel using gda_data_model_query_new(your_select_query), and
call gda_data_model_query_set_modification_query([update|insert|delete]_query)
to allow for update, insert or delete operations. (note that I'm
currently working on making the GdaDataModelQuery create the update,
insert and delete queries by itself).

> >  Here is what happens when the user
> > wants to apply the changes made:
> > 1- the GdaDataProxy sends the GDA_DATA_MODEL_HINT_START_BATCH_UPDATE
> > hint to tell that it will make several modifications at once
> > 2- the GdaDataProxy tries to apply the changes for each row which has
> > been modified, and stops as soon as a change is refused by the
> > GdaDataModelQuery
> > 3- upon asked to do a change, the GdaDataModelQuery tries to run the
> > pre-defined modification query and returns the success status of that
> > query. It also flags itself for a future re-run of its SELECT query to
> > refresh its contents
> > 4- he GdaDataProxy sends the GDA_DATA_MODEL_HINT_END_BATCH_UPDATE
> > hint, and the GdaDataModelQuery re-runs its SELECT query (which makes
> > it change its contents which are propagated up to the grid itself)
> >
> > So the displayed data is always a re-run of the SELECT query of the
> > GdaDataModelQuery object.
>
> So, if the UPDATE fails then the new (failed) value will just be
> refreshed with the old value in the UI, with no message to the user and
> no chance to retry?

Yes, that's currently what's happening. However changing that
behaviour is just a matter of for example adding a "commit_failed"
signal to the GdaDataProxy, for which signal callbacks might return an
action to do such as IGNORE (current behaviour) or
PRESERVE_MODIFICATIONS for example.

Cheers,

Vivien