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

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...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]