Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dataprovider ogr spatialite respect provider defaults #34012

Conversation

@elpaso
Copy link
Contributor

elpaso commented Jan 24, 2020

Fixes #33383

There is also an initial attempt to homogenize defaultValue and defaultValueClause between providers.

See also: https://lists.osgeo.org/pipermail/qgis-developer/2020-January/060007.html

elpaso added 5 commits Jan 23, 2020
Fixes #33383 (for OGR, spatialite commit follows)
Fixes #33383

Homogenization is not complete but at least
there are test cases for the future.
@elpaso elpaso force-pushed the elpaso:bugfix-gh33383-ogr-spatialite-respect-provider-defaults branch from 88f3b9b to f8e255e Jan 27, 2020
@nyalldawson nyalldawson reopened this Jan 27, 2020
@@ -1380,7 +1385,7 @@ QVariant QgsOgrProvider::defaultValue( int fieldId ) const

QString defaultVal = mDefaultValues.value( fieldId, QString() );
if ( defaultVal.isEmpty() )
return QVariant();
return defaultVal;

This comment has been minimized.

Copy link
@nyalldawson

nyalldawson Jan 27, 2020

Contributor

I don't think this change is correct -- there's lots of existing code which checks if the returned value isValid(), and now that will return true instead of false (yet the default value doesn't exist)

This comment has been minimized.

Copy link
@m-kuhn

m-kuhn Jan 28, 2020

Member

And wouldn't the check for mDefaultValues.hasKey be correct here?
Not that an empty string as default value is common, but it's at least in SQL terms it's valid.

This comment has been minimized.

Copy link
@elpaso

elpaso Jan 28, 2020

Author Contributor

That was an attempt to homogenize the behavior, I will revert it and give up with the attempt.

But if you have a look to the tests, you'll see that the actual behavior of the two methods it is totally different between providers (I tested PG ogr and spatialite, but I expect that the others will not behave better).

What they return depends on a permutation of:

  • the fact that it is a literal default or not
  • the fact that it is a particular function/magic-value or not (CURRENT_TIMESTAMP for instance)
  • which provider (and maybe which driver for OGR)
  • if EvaluateDefaultValues is honored and its value

The least we can do is to document it in the API and possibly try to fix it for QGIS 4.

elpaso added 3 commits Jan 28, 2020
... also fixes "Autogenerate" for PKs

Fixes #34085
@elpaso elpaso merged commit ee323eb into qgis:master Jan 29, 2020
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
qgis.QGIS #20200128.37 succeeded
Details
@elpaso elpaso deleted the elpaso:bugfix-gh33383-ogr-spatialite-respect-provider-defaults branch Jan 29, 2020
elpaso added a commit to elpaso/QGIS that referenced this pull request Feb 5, 2020
…te-respect-provider-defaults

Dataprovider ogr spatialite respect provider defaults
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

3 participants
You can’t perform that action at this time.