On 22.12.2014 00:13, Michael Michaud wrote: > 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 concern >>>> >>>>> New 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 branch >>>> not again ;).. we are simply too few devs to maintain anymore than one >>>> proper branch >>>> >>>>> as it may break current code >>>> which 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 define
did you check the new AttributType class. it has methods to determine what is compatible to what. wrt. EditSchemaPlugin.. let's port what we need from Kosmo's version > Shapefile/Dbf : dbf specification is weird (numeric as text with length + > decial places, > date as text, boolean as case insensitive text...) you can insert a schema test into the shapefile writer, which will complain for the new AttributeTypes >>> 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 we might check Kosmo's shapefile writer wrt. that >> >>>>> 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? > Not much, but we can discover easily many places to fix before letting more > users help us discover corner cases. as i don't use OJ, i'd rather have actual users find these >>>>> 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 > Yes but bigdecimal, numeric and decimal have the same internal representation > (bigdecimal). > See after. if you say so,i believe it. makes sense anyway. >>> 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. > 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. > > 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) so they serve a purpose > My opinion is that it adds confusion for a basic usage of OpenJUMP, but let's > submit > the discussion to the group. agreed > I did not keep tinyint and float because I think they are relics of old times > (16 bits processors) are you sure that they are not used in some database context? > I hesitate for time and timestamp as managing / formatting date / times is > often much troubles > and current Dates can already store timestamps. > what attribute types are used in common GIS software? do they limit the choices or rather support many, albeit the lot is probably represented by few internally? Jukka, what do you have to say? ..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
