The recordset class

You have to extend one of GdaDataModel(3), GdaDataModelArray(3) or GdaDataModelHash(3). The easiest to extend are the last two. They both derive from GdaDataModel(3).

Here is the list of methods that you have to override. If you use GdaDataModelHash(3), you don't need to override append_row.

• get_n_rows

  Returns the number of rows in the data model. If the provider can know in advance the number of rows the database server has returned, this function should just return that, and not retrieve any data. On the other hand, if it can't it should either retrieve all data, or move to the last record in the recordset and retrieve the row number, if the underlying data source allows it.

• get_n_columns

  Returns the number of columns in the data model.

• describe_column

  Returns information about a given column, in the form of a GdaFieldAttributes.

• get_row

  Retrieves a row from the data model. This function is very important for the implementation of editable data models. What this function returns is a GdaRow">GdaRow, which providers should uniquely identify (via gda_row_set_id). This is needed so that later on, client applications can use the same GdaRow returned by this method in the update_row and remove_row methods.

• get_value_at

  Returns the value stored in a given cell of the data model.

• is_editable

  Checks whether the data model can be modified or not. If the provider supports the edition of data models, it should return TRUE in this function. If it doesn't (for instance, because it can't uniquely identify rows in the data model), it should return FALSE.

  Before a data model can be edited, client applications must call the gda_data_model_begin_edit function, which emits the "begin_edit" signal on the GdaDataModel class. So, providers should connect to this signal to be informed when the data model starts being editing. In the callback connected to that signal, it should start a transaction, for instance.

  In a similar way, there are 2 other signals that provider's data model implementations should pay attention to. Those are "end_edit" and "cancel_edit". In "end_edit", if all went ok, providers should COMMIT the transaction started in "begin_edit". In "cancel_edit", a ROLLBACK should be made.

• append_row

  Appends a row to the data model. Usually, this means, in the provider, executing an INSERT SQL command on the table being read by the data model.

• update_row

  Updates an existing row in the data model. The row should have been uniquely identified in the provider code, as explained for the get_row method.

• remove_row

  Removes a row from the data model. Usually, this means, in the provider, executing a DELETE SQL command on the table being read by the data model. The row should have been uniquely identified in the provider code, as explained for the get_row method.