Martin, > I have just two comments: > - is the alternation of hte field definition going to have some rules > how the existing data should be converted to the new type or will the > driver itself choose how to convert the data? The latter option is > surely the easier one, but it would be probably good to guarantee at > least some expected conversions: int <-> text, float <-> text, round > the number when lowering precision etc.
I've added a new section 'Altering field types' in the RFC : """ This RFC does not attempt to guarantee which type conversions will be possible. It will depend on the capabilities of the implementing drivers. For example, for database drivers, the operation will be directly done on the server side (through a 'ALTER TABLE my_table ALTER COLUMN my_column TYPE new_type' command for the PG driver). So some conversions might be possible, others not... It is however expected that converting from any type to OFTString will be supported in most cases when AlterFieldDefn() is supported. Drivers that don't support a conversion and that were required to do it (ALTER_TYPE_FLAG set and new_type != old_type) should emit an explicit error. """ I've also implemented the conversion from any type to OFTString for the shapefile driver and upload a v3 of the patch. Converting from text to a numeric type seems difficult, because you have no guarantee that the content of all features for this field is numeric... So this would raise the question : what to do when the conversion is not possible for at least one value ? : refuse the whole conversion, or convert what can be converted and put some default value in case the conversion is not possible. To come back to the PG driver, it refuses to convert from string to integer, even when it is possible. From the error message, I suppose it would need a USING clause to provide a conversion expression, but I didn't go as far as this for now. Hence the rationale for not promising too much in the RFC. > - what is actually the motivation behind reordering of the fields? Is > that just for aesthetical reasons? (e.g. zip code should be next to > the city name) The reasons given by Stephen are quite good. I mainly implemented it for the completness of the possible field manipulations, as suggested by Frank in ticket #2671. One use case I see is an improved user experience when you open a table and want to see the most significant columns at the beginning without needing to scroll to the end. I'm not sure which drivers, apart from shapefile, will be able to implement it actually. There are not so many formats that can implement reordering of fields in place. The implementation in some cases might be possible by using an intermediate temporary file. This would be needed for example to implement this for any text based format, such as CSV, but for that very same reason, CSV driver cannot add a field to a layer where features have already been written). Tanks for your comments, Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
