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

[Bas Driessen <bas driessen xobas com>]

On Mon, 2006-08-28 at 14:57 +0200, Vivien Malerba wrote:
>     
>     
>     On 8/28/06, Bas Driessen <bas driessen xobas com> wrote:
> >         
> > >             
> > >             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 ...)
> >     
>     
>     It is provider dependant regarding data types, I admit. The point is to set the barrier between something "relatively" simple and tolerant and something too restrictive considering the huge differences between the providers regarding non DML queries while still retaining _all_ the features one provider offers. 
>     
>     But saying that the old situation allowed to specify a GType and it would automatically be converted to the correct DBMS dependant type is false. I've never seen that. Moreover the gda_server_provider_get_default_dbms_type() call allows exactly to convert a GType to a DBMS dependant data type which you can use to avoid your problem. 
>     

OK, the gda_server_provider_get_default_dbms_type() may be a way to go and will investigate that path. Not sure if that will cater for the set_scale (gda_column_set_scale() type of thing), but will find out.

Don't get me wrong Vivien, I am not knocking your work. On the contrary, all the new functionality is great, I only wish that there would finally be an API freeze. (Or even regular developer releases, we have been way too long on 103 now). It is just time-consuming to keep rewriting existing code and as a result it is doing the same. Version 1.2 is too much behind in functionality. There could easily have been a version 2 in the middle. From a production point of view, things are even worse to handle because of all this. Hopefully all will be finalized soon. Also the web pages are hopefully outdated and not really attractive for any new users. It looks like the project needs some management... ;-)

Bas.