On 18.03.2015 16:00, Rahkonen Jukka (MML) wrote: > Hi, hihi.. would never have guessed to live to the day you loose your cool :))
> > I was trying to generate some test data for finding out possible problems > with shapefile output-input. > > - Auto Assign Attribute does not recognize new attribute types like > Smallint at all > > - Replace Attribute Value cannot replace values in Smallint field > > - It is possible to create Smallint field but not possible to change > Integer into Smallint if the field does not contain all NULLs. > > - If layer contains field of type Smallint it is not possible to do > further edits into the schema. it's to be expected that some plugins won't work with the new types instantly > We have now an experimental feature in development version of OpenJUMP which > does work for writing/reading JML but not for anything else really. It would > be wrong to say that the nightly builds are broken because there are no > troubles if the new datatypes are not used. exactly, no harm no foul.. > I would have rather seen new datatypes added one by one, or in batches, but > in such a way that at least the core functions and most important plugins had > been tested and corrected to support those. sure, but who will take the time to do one by one? who even knows _all_ plugins that might have issues with the new types. >If new data types are not supported we should at least give some reasonable >hint or error message about that for the users. > > Could we have something like "Allow experimental data types" check box in the > Schema editor view, default "No"? When Michaël gets the work with Boolean and > Long finalized they could be tagged as safe data types. sounds reasonable >However, even that work is not ready to be included in a new official OJ >release: not even as experimental? with the switch you mentioned? > > - Check mapping data types for import/export of all supported data > type we have many different datasources with different devs being knowledgeable about them. > > - Check all tools. I fear that most of them can't handle Boolean or > Long at the moment same all issue and i would argue that if they don't work with these types we should fix converting them via attribute table, so users can workaround that but issue a ticket. > - Check core plugins > > - Check other extensions like above > I would like to keep OpenJUMP as a high quality and relatively bug free > program also in the future - A small open source GIS that can. > yes and no. for the future i'd like to have users betatesting OJ more, which also means to have let them new unpolished functionality. a first step was the snapshots and the latest was having only one dev trunk that at one point is declared release worthy. we really are understaffed and i feel our users appreciate what they get and won't mind if new features will not work flawlessly from the very start. wrt. the new datatypes - it was an easy port to get them from Kosmo. generally we already had the need for LONG and BOOLEAN. the others are mere decorative to allow keeping more elaborate schemas. we should have no datasource that uses them currently (eg. our db connectors probably will map all non decimal numbers to INT). hiding the new datatypes from the user and adding the switch to the schema editor seems like a good compromise to me. every journey starts with a first step ..regards ede ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
