On 9/2/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-09-01 at 09:15 +0200, Vivien Malerba wrote: > > On 9/1/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2006-08-30 at 17:15 +0200, Vivien Malerba wrote: > > > > On 8/30/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 2006-08-30 at 15:36 +0200, Vivien Malerba wrote: > > > On 8/30/06, Bas Driessen <[EMAIL PROTECTED]> 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. Thanks, Vivien _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
