[QGIS-Developer] Data provider default values and default value clause

[Alessandro Pasotti]

Hi Nyall,

thank you for confirming my worst nightmares :)

Unfortunately, since the data providers are certainly a foundation
component of QGIS, these behavior inconsistencies lead to issues in client
code (GUI/UX mainly but probably also in QgsVectorLayerUtils create
features functions) and I believe we should try hard to find a solution.

Do you think it is a wast of time (because as you mentioned some providers
can't tell the difference between a literal and an expression)?

I've done a PR that does not completely fix all the issues but at least
adds some tests and fixes a few things:
https://github.com/qgis/QGIS/pull/34012



On Mon, Jan 27, 2020 at 7:44 AM Nyall Dawson <nyall.dawson at gmail.com> wrote:

> On Fri, 24 Jan 2020 at 19:28, Alessandro Pasotti <apasotti at gmail.com>
> wrote:
> >
>
> > 1. From the docs it seems that the defaultValueClause() should ONLY
> return clauses (like sequences, functions, CURRENT_TIMESTAMP etc.) and
> should NOT return literal defaults.
>
> Correct. However -- not all providers are completely well behaved in
> this regard. Some of these are because of limitations on the provider
> itself, e.g. there is no way to different literal defaults from
> clause-type defaults on the associated backend. When we can't
> differentiate the two, we err on the side of returning a
> possible-literal value from defaultValueClause (and not the reverse
> and accidentally return a non-literal value from defaultValue() ).
>
> > 2. From the docs it seems that defaultValue() should return ONLY literal
> defaults and NOT functions, ::nextval and friends
>
> Correct (and should ALWAYS be the case)
>
> > 3. OGR provider does return the actual client-side calculated value when
> calling defaultValue() ONLY in case of literal defaults and
> CURRENT_TIMESTAMP, CURRENT_DATE and CURRENT_TIME, it returns the clause
> definition in all other cases, is this correct?
>
> Yes - it's deliberate, even thought it slightly violates the above
> answer to (2) in that for this provider we pre-calculate these
> quasi-literal values on the qgis side.
>
> > 4. postgres provider in case the property EvaluateDefaultValues is true
> does something more and send the clause to the server for evaluation,
> returning the calculated value, otherwise it returns the clause definition.
>
> That's correct also, and by design. As per the warnings in the
> defaultValue() docs, defaultValue calls are potentially dangerous to
> make and should only ever be done when creating features (and in that
> situation, only ever called once per field per feature). Otherwise
> when EvaluateDefaultValues is true we run the risk of evaluating
> sequences multiple times for a single feature, causing "gaps" in the
> sequence.
>
> > 5. What to return in case of no defaults? Depending on provider and
> field types, some implementations return a NULL (QVariant()), some others
> return a Python None.
>
> Slight correction: QVariant() != Python NULL. Rather QVariant() ==
> Python None, and QVariant( QVariant::Int ) == Python NULL. The c++ api
> doesn't usually differentiate between the two and QVariant() is more
> commonly used. (And I personally think in 4.0 we should completely
> remove the PyQGIS NULL/QVariant( QVariant::Int ) distinctions -- they
> add much complexity to code without compelling enough benefits).
>
> Short answer: return QVariant() when no default literal exists.
>
> > So, I'm confused about the expected behavior, if the documentation of
> defaultValue() and defaultValueClause() is correct then the provider
> implementations are (at least for some of them) wrong.
>
> Hope that clarifies!
>
> Nyall
>
> >
> > I'd like to hear other developer's opinion before proceeding with a fix
> for the a.m. providers.
> >
> > Thank you in advance!
> >
> > --
> > Alessandro Pasotti
> > w3:   www.itopen.it
> > _______________________________________________
> > QGIS-Developer mailing list
> > QGIS-Developer at lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200127/9dbdb78b/attachment.html>