Re: [gnome-db] Data Types translations.

[Bas Driessen <bas driessen xobas com>]

On Sat, 2006-09-02 at 15:34 +0200, Vivien Malerba wrote:
> On 9/2/06, Bas Driessen <bas driessen xobas com> wrote:
> >
> >  On Fri, 2006-09-01 at 09:15 +0200, Vivien Malerba wrote:
> >
> >  On 9/1/06, Bas Driessen <bas driessen xobas com> wrote:
> > >
> > > On Wed, 2006-08-30 at 17:15 +0200, Vivien Malerba wrote:
> > >
> > > On 8/30/06, Bas Driessen <bas driessen xobas com> wrote:
> > > >
> > > > On Wed, 2006-08-30 at 15:36 +0200, Vivien Malerba wrote:
> > > > On 8/30/06, Bas Driessen <bas driessen xobas com> wrote:
> > > > [...]
> > > >
> > > >
> > > >
> > > > >
> > > > > Further to the discussion regarding the creation of the table. There
> > is
> > > > the > Path: /FIELDS_A/@COLUMN_TYPE. Here a complete type must be set.
> > For
> > > >
> > > > postgresql that is varchar(30) for instance. As mentioned before I would
> > >
> > > > like to see this part more provider independent. Perhaps we can reach
> > some
> > > >
> > > > sort of a compromise. First I tell you what I would like to see: > >
> > > > /FIELDS_A/@COLUMN_GTYPE > /FIELDS_A/@COLUMN_SIZE >
> > /FIELDS_A/@COLUMN_SCALE
> > > >
> > > > > example values: > GDA_TYPE_NUMERIC > 10 > 2 > > This then will be
> > > > translated by the postgresql provider for instance to > numeric(10,2). >
> > >
> > > > To provide both options to the user, we can say that if >
> > > > /FIELDS_A/@COLUMN_TYPE (the current situation), this overrules any >
> > > > situation. If it is not set, the user should set > >
> > > /FIELDS_A/@COLUMN_GTYPE
> > > > > /FIELDS_A/@COLUMN_SIZE (if applicable) > /FIELDS_A/@COLUMN_SCALE (if
> > > > applicable) > > Then for the various providers we can make this into
> > > > something that works > for the data provider. > I agree on having the
> > > > /FIELDS_A/@COLUMN_SIZE and /FIELDS_A/@COLUMN_SCALE as this makes things
> > > more
> > > > provider independant. However I prefer to stay with a
> > > /FIELDS_A/@COLUMN_TYPE
> > > > because it's closer to what a user can easily fill-in and it's easy for
> > a
> > > > programmer (using
> > > > gda_server_provider_get_default_dbms_type()) to convert
> > > > from a GType to a DBMS type. It also makes it possible to check and take
> > > > actions when the provider doesn't support a particular GType before
> > trying
> > > > to execute the action. So I propose to have /FIELDS_A/@COLUMN_TYPE
> > > > (required) /FIELDS_A/@COLUMN_SIZE (optional) /FIELDS_A/@COLUMN_SCALE
> > > > (optional) Is it Ok for you? If so, can you make the modifications in
> > the
> > > > xml.in files and in the -ddl.c files for some or all of the providers?
> > > > Ok with me, but if you bring back everything to just COLUMN_TYPE (as
> > > > opposed to also have COLUMN_GTYPE), how would you deal with the
> > situation
> > > if
> > > > a user sets the values as follows:
> > > >
> > > > numeric(10,5) (rather than GDA_TYPE_NUMERIC)
> > > > 10
> > > > 5
> > > >
> > > > In this case we should ignore the size and the scale, since
> > > > numeric(10,5)(10,5) is rubbish of course. What is the best approach to
> > > deal
> > > > with this you reckon?
> > >
> > > This is a potential problem and whatever we end up doing, the user
> > > will always have the responsibility to avoid entering stupid things
> > > (my point is that we can't make something completely water-proof).
> > >
> > > So I suppose in this case we should just notice that there are
> > > parenthesis and then ignore the /FIELDS_A/@COLUMN_SIZE and
> > > /FIELDS_A/@COLUMN_SCALE values, just as we should ignore them when the
> > > data type does not support size and scale attributes.
> > >
> > > >
> > > > I am more than happy to make the changes for the postgresql and mysql
> > > > providers. Once I have everything stable/working again, I want/have to
> > > look
> > > > into the Oracle provider as well. I need to bring that to the same level
> > > in
> > > > libgda as mysql and postgresql (including recordset etc etc).
> > >
> > > Ok, great!
> > >
> > > BTW: do you have/want a gmail account so it is possible to do some chat?
> > >
> > >
> > > OK Vivien will start working on the SIZE/SCALE this weekend.
> >
> > Ok, I think I'll roll out a beta this WE, and I'll merge tour
> > modifications after it.
> >
> >
> >  I have made the modifications for the Postgresql provider. Tested OK and
> > committed to CVS. Please review/test and let me know any issues. Will work
> > on the MySQL provider next.
> >
> >  It is pretty impossible to make this optional SIZE and SCALE water-proof as
> > discussed before. I decided not to check for parenthesis etc at all, so the
> > user will see in their error output what goes wrong. If we start making
> > assumptions that if a user typed a parenthesis we should not add ours etc,
> > we may get burned at some stage with some special type in some special
> > situation.
>
> Yes, I agree with you. I've just modified a but the
> providers/postgres/postgres_specs_add_column.xml.in because you
> specified a default value
> for the COLUMN_SIZE and COLUMN_SCALE (using a <gda_value> tag) equal
> to "guint" which is not a unsigned integer value, so I removed
> altogether the defaulf value, thus leaving it to NULL.
Changes applied for MySQL and SQLite as well. I don't have SQLite operational here so could not test, but based on the changes I did for Postgresql and Mysql all should work OK. Also removed the default values as pointed out by Vivien. Please review and let me know any issues. I will (try to) get the "create index" part to work now in my project and will address any libgda issues in that area if there are any. After that my plan is to work on to Oracle interface and bring that to the same level as the mysql and postgresql providers.

Thanks,
Bas.