Re: [gnome-db] How to create define size/set scale with GdaServerOperation.

[Bas Driessen <bas driessen xobas com>]

On Mon, 2006-08-28 at 13:50 +0200, Vivien Malerba wrote:
>     
>     
>     On 8/28/06, Bas Driessen <bas driessen xobas com> wrote:

Hello Vivien,

An example XML data structure to create a table using this GdaServerOperation is as follows:

const gchar *params = "
<serv_op_data>
  <op_data path="/TABLE_DEF_P/TABLE_NAME">testtable</op_data>
  <op_data path="/FIELDS_A">
    <gda_array_data>
      <gda_array_row>
        <gda_array_value colid="COLUMN_NAME">id</gda_array_value>
        <gda_array_value colid="COLUMN_TYPE">int</gda_array_value>
      </gda_array_row>
    </gda_array_data>
  </op_data>
</serv_op_data>"

How would I define a column of VARCHAR with length of 30 for instance? I can not find details regarding COLUMN_TYPE in the latest documentation. Can still use data provider independent settings like G_TYPE_STRING? How would I define a size (like the old gda_column_set_defined_size() )  and how would I set a scale (like the old gda_column_set_defined_size()). I don't see them in your table 3 (see below):

Please advise.

Thanks,
Bas.



Table 3. 

Path	Type	Required?	Description
/TABLE_DEF_P	PARAMLIST	Yes	Table's description
/TABLE_DEF_P/TABLE_TABLESPACE	PARAM		Tablespace in which to create the table (string)
/TABLE_DEF_P/TABLE_NAME	PARAM	Yes	Table name (string)
/TABLE_DEF_P/TABLE_TEMP	PARAM		TRUE if the table to create is temporary (boolean)
/TABLE_DEF_P/TABLE_COMMENT	PARAM		Comment on a table (string)
/FIELDS_A	DATA_MODEL	Yes	Table's fields description
/FIELDS_A/@COLUMN_NAME	DATA_MODEL_COLUMN	Yes	A table's field name (string)
/FIELDS_A/@COLUMN_TYPE	DATA_MODEL_COLUMN	Yes	A table's field type (string)
/FIELDS_A/@COLUMN_NNUL	DATA_MODEL_COLUMN		TRUE if table's field can't be NULL (boolean)
/FIELDS_A/@COLUMN_AUTOINC	DATA_MODEL_COLUMN		TRUE if table's field must be auto incremented (boolean)
/FIELDS_A/@COLUMN_UNIQUE	DATA_MODEL_COLUMN		TRUE if table's field must be unique (boolean)
/FIELDS_A/@COLUMN_PKEY	DATA_MODEL_COLUMN		TRUE if table's field is a primary key (boolean)
/FIELDS_A/@COLUMN_DEFAULT	DATA_MODEL_COLUMN		A table's field default value (string)
/FIELDS_A/@COLUMN_CHECK	DATA_MODEL_COLUMN		A table's field CHECK condition (string)
/FIELDS_A/@COLUMN_COMMENT	DATA_MODEL_COLUMN		A comment on the table's field (string)
/FKEY_S	DATA_SEQUENCE		Sequence representing foreign keys description
/FKEY_S/FKEY_REF_TABLE	PARAM		The foreign key's referenced table (string)
/FKEY_S/FKEY_FIELDS_A	DATA_MODEL		The foreign key's field's being used
/FKEY_S/FKEY_FIELDS_A/@FK_FIELD	DATA_MODEL_COLUMN		A foreign key's field's from the table to create
/FKEY_S/FKEY_FIELDS_A/@FK_REF_PK_FIELD	DATA_MODEL_COLUMN		A foreign key's field's from the referenced table
/FKEY_S/FKEY_ONUPDATE	PARAM		The action to take when the referenced field is updated (string)
/FKEY_S/FKEY_ONDELETE	PARAM		The action to take when the referenced field is deleted (string)
/FKEY_S/FKEY_DEFERRABLE	PARAM		TRUE if the foreign key is deferrable until the end of a transaction (boolean)
/TABLE_CONSTRAINTS_S	SEQUENCE		Sequence representing table constraints
/TABLE_CONSTRAINTS_S/CONSTRAINT_STRING	SEQUENCE		A table constraint (string)

>     
>     
>     The COLUMN_TYPE value can be like "VARCHAR" or "VARCHAR(30)" or "SERIAL" or whatever the provider unserstands. You can't use something like G_VALUE_STRING as providers don't know about that. 
>     

Oh No !!! Why have you made it provider dependent on this level? The whole idea of libgda is to have a provider independent interface. The old situation was perfect where you could use values as G_TYPE_STRING or G_TYPE_INT64 etc etc and libgda would take care of the rest. For my programming I did not need to know what the actual data-provider is. Now I am forced to find out what the data provider is and create all kinds of if statements, create massive redundant code and do the work libgda is supposed to do.  Is there any way to make it more provider independent, or at least give us a choice (or give us back the old functionality which was working perfectly and required little coding only ...)

Not happy ...

Thanks,
Bas.