On 8/28/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-08-28 at 14:57 +0200, Vivien Malerba wrote: > > > > > On 8/28/06, Bas Driessen <[EMAIL PROTECTED]> 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
