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