Re: [gnome-db] GDA xml and questions

["Vivien Malerba" <vmalerba gmail com>]

On 1/24/07, Sandro Dias Pinto Vitenti <sandro isoftware com br> wrote:
> Hi,
>
> I'm studding libgda and have some questions:
>
> 1 - Make any difference to put a nullok='TRUE|FALSE',
>      inside a parameter description in a query?
>      Like those in the example of
> gda_data_model_query_set_modification_query
>      usage, delivery_before=## [:name="+2" :type="date" :nullok="TRUE"]?

It won't make a difference to the query itself, but if you specify
nullok='FALSE' and if you try to set a NULL value to the corresponding
parameter prioir to executing the query, then you'll get an error (the
GUI will also tell you that there is an error).

BTW, the syntax has changed in recent versions of libgda and the above
query would now be:

usage, delivery_before=## /*name:"+2" type:"date" nullok:TRUE*/

> 2 - I think that the dictionaries using xml idea is great, is it original?
>      Is there another implementation like that?

I have no idea, but I don't know of any other project which uses a
dictionary as libgda does.

> 3 - In the xml, why use long names like 'gda_dict_types'. Could we just
> use 'types' and a
>      'gda' or 'gda_dict' namespace when needed?

Yes, it could be done, but what's the point of changing it now?

> 4 - Why do you use all those ids in the xml? Look like you did that to
> easily translate
>      to a hash table. But it wouldn't be better use xpath more
> extensively? For example,
>      /gda_dict/gda_dict_types/type[ name='xxxxx'] to get a type named
> xxxxx or

The XML representation is only used as a storage medium: once the
dictionary is loaded, the XML tree is destroyed, and information
lookup is done within the dictionary structure (composed of GdaDict*
objects). Also in the future, the dictionary will probably contain
elements which can't be translated as XML.

> /gda_dict/gda_dict_database/gda_dict_tables/gda_dict_table[ name='table1']/gda_dict_field
>      to get all fields from table 'table1'.
>
> 5 - gda_dict_constraint shouldn't be a child of
> gda_dict_table|gda_dict_field?

That solution was not used because I wanted all the constraints to be
managed by a unique object to make things easier, and so it could not
be a GdaDictTable or GdaDictField, but the GdaDictDatabase was Ok.

Cheers,

Vivien