Item8838: No "undefined" value in queries

pencil
Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
Reported By: CrawfordCurrie
Waiting For:
Last Change By: KennethLavrsen
There's no way to determine if something is defined during a query search. For example, I might have three cases:
  1. %META:FIELD{name="Blah" value=""}%
  2. %META:FIELD{name="Blah" value="0"}%
  3. No definition of Blah
We can currently distinguish the first and second cases using the = operator:
  • Blah=0
  • Blah=''
However the "No definition of Blah" case cannot be distinguished from the empty definition case. The specific use case I have is where a form has been modified to add a field; I need to find all topics that don't have the field definition. Query search is currently unusable for this.

The problem arises because the query evaluator interprets 0 and the empty string as boolean false (a familiar problem for all perl coders).

The perl approach to this is to define operators that test defined and exists (where defined means "does not have the value undef" and exists means "the element exists in the given array or hash"). I find this obscure and confusing, and prefer the Javascript approach of having distinct undefined and null values (where "undefined" means "this has never been assigned a value" and "null" means "has been assigned a value, but that value is null"; thus Javascript null is the equivalent of perl undef).

Anyway, I think the best solution is to support the reserved name undefined to represent the undefined value. This is low risk, as it would only impact users who have used the name "undefined" for a field name. That leaves us with the option of adding "null" when we work out how to store a null value.

-- CrawfordCurrie - 04 Apr 2010

It occurs to me that as long as the user hasn't created a field called "undefined" then this already works in queries. This is because an undefined field name will yield the undefined value, which will then be comparable according to the existing rules. So this is a pure documentation (and unit test) fix.

-- CrawfordCurrie - 04 Apr 2010

surely we should also have some way to determine if a datum is in the current version of the Form definition too?

ah, yup, I do already do compare to something i know isn't supposed to be there - though I prefer the language to be specific, i find JS's specificity annoying at times.

-- SvenDowideit - 04 Apr 2010

I don't understand; you mean we should have some way of querying the form schema? I was deliberately staying quiet on that topic while it was discussed elsewhere....

-- CrawfordCurrie - 04 Apr 2010

I restructured the QueryTests so that they also invoke the query algorithm, thus testing the store impl.

-- CrawfordCurrie - 04 Apr 2010

 

ItemTemplate edit

Summary No "undefined" value in queries
ReportedBy CrawfordCurrie
Codebase 1.0.9, 1.0.8, 1.0.7, 1.0.6, 1.0.5, 1.0.5 beta1, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.0 beta3, 1.0.0 beta2, 1.0.0 beta1, trunk
SVN Range
AppliesTo Engine
Component
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:b44a09b4a1c7 distro:da49fc5906a0 distro:9e54acc99522 distro:757ea1232d15
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r10 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy