On 21.12.2014 18:37, 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? > 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 >>> 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? >>> 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 > 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. ..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
