Actually it had nothing to do with CSV being the
source, but it was the json exporter passing
the values through all field formatters except for
the fallback.
This resulted in all fields using a 'Range' formatter
(which is the default for all numeric types) passing
through the formatter and being returned as strings
in the json. Worse, if the locale was not a "dot"
locale and decimal separator was on, the resulting
string could not be easily converted into its original
numeric type.
Now, instead of checking for the fallback formatter
only, there is a white list of formatters that
can be applied when we want a json.
This is a temporary solution because the "right" way
to do it would be either a flag in the formatter to
tell if it can be applied when converting to json
and/or other "data" formats (csv etc.) or a different
new method similar to representValue.
In order to add a PostgreSQL layer based on a view, one needs to explicitly
pick one or more columns to serve as the primary key. However in both browser
dock and in the DB manager user can add a view as a layer without specifying
primary key. Users get confused about this behavior, therefore this commit
makes the Data Source Manager behave consistently with browser and DB manager,
that is it will pick the first column as the proposed primary key automatically.
While this may be a bit risky in letting user use wrong pkey, it is very
convenient (and consistent with other part of QGIS). Also, usability of selection
of geometry type / srid / pkey column(s) is not great so it is good not to force
people to always choose pkey for their views. The list will still keep
the warning icon and tooltip shown as before.
* fixes#16047
* extracts band name info using gdalapi in QgsGdalProvider
* added configuration option to allowing user to select band name behavior
* currently 5 ways including current default behavior: #, name, name (#), # (name), _DIM_EXTRA metadata
- Add 'refresh' action to allow display of displays created outside
of QGIS
- Show empty schemas in browser too, as they can be useful for
drag and dropping new data sets to import into
- Add create schema item
Adds a QMessageBox if file exists
Remove lastDatabase setting to lastDirDatabase. It's dangerous to reuse
the last database.
Adds a .gpkg extension to filename if not presents.
Because we can no longer overwrite tables directly using drag
and drop (refs #16805), add some explicit actions which allow
dropping existing tables (after user confirmation, of course!)
- Use [] to correctly quote field names instead of ""
- Don't invalidate provider side limit when not required
Forward port of 8dec70c, because I'm only human and forgot
Sets whether the connection should skip all handling of records with
invalid geometry, which are slow and costly.
This speeds up the provider, however, if any invalid geometries
are present in a table then the result is unpredictable and may
include missing records. Only check this option if you are certain
that all geometries present in the database are valid, and any newly
added geometries or tables will also be valid!
Why would we want this? Well, SQL Server invalid geometry handling
is AWEFUL. A seriously lame, data mangling and corrupting
piece of s***. Use Postgres instead. But if you can't, then you
can at least choose to use your layers at full speed, if you
can take the responsibility that a SINGLE invalid geometry
hiding somewhere in the table will result in a whole bunch
of missing (valid) features.
SQL server is at fault here, not us. There's nothing we (or
GDAL, or MapServer, or GeoServer, or anyone else) can do
to fix this.
Suffice to say, this option is off by default, as we're better
to have a slow provider which actually shows all features.
Fixes#15752
Rant over
