Re: [gnome-db] Data Types translations.



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.


 Do not have gmail as I don't want to place my private stuff on 3rd party
servers. Very off-topic, but why do I need gmail for a chat? Don't we have
IRC channels for that and SIP protocol for voice etc?

From work I cant' access any IRC or other SIP servers, in fact I can
only have email and web access, so GMail is very convenient there (as
it has email and chat).

Cheers,

Vivien



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