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 <[email protected]> wrote: > On Fri, 24 Jan 2020 at 19:28, Alessandro Pasotti <[email protected]> > 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 > > [email protected] > > 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
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
