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

["Vivien Malerba" <vmalerba gmail com>]

On 8/28/06, Bas Driessen <bas driessen xobas com> wrote:
>  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... ;-)

Don't worry, I'm not upset at all! and having comments (even negative
ones) is always welcome to avoid mistakes...

I totally agree with you about the API freeze and release. To tell you
the truth I've spent my time lately on cleaning the API and making
sure we won't have any trouble making new releases later not breaking
API and ABI compatibility. I'll commi tmy latest changes ASAP (tonight
maybe) and then I'll roll a new snapshot (beta) version.  I agree we
have waited too long...

Cheers,

Vivien