Hi,
You made a big change on AttributeType class last thursday, It's a very interesting change with a lot of potential, but my concern is how much code it will break, and how much time it will take to upgrade all the code depending on this class.valid concernNew data types you inroduced are already available in Edit Schema plugin, but many drivers/plugin are not ready to manage these new types.that was my intention and we have to start somewhere. the commit as such does not break a thing. when people start using the new attribute types and trun into errors we can start fixing them.From my point of view, this is the kind of change which may justify to create a new branchnot again ;).. we are simply too few devs to maintain anymore than one proper branchas it may break current codewhich code do you have in mind?Just create a new layer with a boolean type, edit a feature to set the boolean attribute to true or false, you are done, you can no more edit the schema, you can no more save the dataset to a shapefile...that should be easy to fix.. shouldn't it?
Not that easy :Edit Schema : it includes capabilities to cast attributes from a data type to another.
The more data types, the more rules to defineShapefile/Dbf : dbf specification is weird (numeric as text with length + decial places,
date as text, boolean as case insensitive text...)
Pieces of code which will probably be broken as soon as new attributes values will be used : drivers : shapefile driver, postgis driver, extension drivers... tools based on attribute like attribute agregators, queries... Just checked : more than 100 classes use AttributeType class. It does not mean all have to be fixed, but I would say most of them will have to.totally correct, and they will still be - unless we start somewhere
I think priority n°1 is shapefile
Not much, but we can discover easily many places to fix before letting more users help us discover corner cases.for an undetermined laps of time.shouldn't it break nothing? the "old" attribute types will continue to work as good as before. readers will probably still use the old datatypes and _only_ if the user switches the change will become effective, non?Yes I think that OJ should continue working as before as long as the user does not use new attribute types.which you did in the example above ;)I think we could hide new attribute types in stable releases as long as major fixes have to be done.yeah, thought about that too. we could enable types in a configuration panel, for power users to activate. problem though, how many power users are there to actually use it and report issues?
Yes but bigdecimal, numeric and decimal have the same internal representation (bigdecimal).What do you think ? Is it an intentional commit ?yes. a first step, nothing more, nothing less.Are you aware of all the dependencies ?the topic comes up from time to time, but we shy away from it. so why not start? do you have an issue at hand, that breaks OJ's general usability because of this commit?OK, nothing impossible. Just think it should be evaluated as soon as possible, because if we work in the trunc, when we will have upgraded tens of classes, we'll have to finish the work ;-)we are aiming for an ideal, which in the true sense of the word, cannot be reached at all. so let's simply try the possible.Also I have seen that most of database types have been included by kosmo, even datatypes which have the same internal representation (decimal/numeric/bigdecimal).yeah, but bigdecimal can hold greater numbers
See after.
I started a document to sum up problems concerning data type transposition (here attached). First column contains OpenJUMP 1.8 AttributeType and second column contains Kosmo AttributeTypes.I think we can just wonder why we add these types ? I think that some data types really add capabilities (boolean, long), but I like simplicity and I wouldn't like to add 10 new types just because it's as cheap as adding 2 of them.sure, if they are truly identical we might throw them out. do as you please.
My suggestion is to keep the green ones.There are many AttributeTypes with the same java internal representation in kosmo. I don't say they are useless. I think they have been added in order to match more precisely database data types (which makes it possible to keep track of true data types used in the
database in certain circumstances)My opinion is that it adds confusion for a basic usage of OpenJUMP, but let's submit
the discussion to the group.I did not keep tinyint and float because I think they are relics of old times (16 bits processors) I hesitate for time and timestamp as managing / formatting date / times is often much troubles
and current Dates can already store timestamps. Michaël
..ede ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
data_types.ods
Description: application/vnd.oasis.opendocument.spreadsheet
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
