Roundup Tracker - Issues

Message3794

Author tobias-herp
Recipients ajaksu2, ber, richard, schlatterbeck, tobias-herp
Date 2009-07-15.09:18:38
Message-id <1247649519.85.0.677124751558.issue1182919@psf.upfronthosting.co.za>
In-reply-to
Now the date problem, and the default nature of ranges.

*Currently*, the only existing ranges have an /including/ (if any) lower
limit, and an /excluding/ (if any) upper limit.

This is the result of such ranges being supported for date values only,
and we simply compare to the 0:00 values of the given days:

  2009-07-13;2009-07-15

finds the records for /two/ days only instead of three, because the
field values x are simply compared to the 0:00 values:

  2009-07-13.00:00 <= x < 2009-07-15.00:00

Thus, to find the records of days date1 to date2, you currently must add
1 to the upper limit:

  date1;date2+1

(of course, you must calculate "date2+1" yourself before sending the
request).

This is inconvenient.
For numbers, this is not only inconvenient but inappropriate:

Consider a user who is about to seek

  8 13

(the set {8, 13}, like currently supported for ids)

Then (s)he thinks about it and decides to better /include/ the
intermediate values:

  8; 13

(inserting the range operator).

Of course, (s)he will expect the result to /include/ the specified upper
limit.  This is the kind of things which must work as expected.
Therefore, ranges must be inclusive by default.

This changes the result of some existing stored queries:  those which
specify a day (especially /without/ a time specification) as the upper
limit.  Therefore, *for dates* this changed default can't be activated
automatically:  We need

- a configuration switch to allow the tracker admin to choose
  whether and when to active the new default
- a conversion script to change the affected stored queries.

BTW, this is one more argument to demand explicit range brackets when
the existing range syntax is stepped beyond:
- the incompatibility affects the /default/ nature
  of /date/ ranges only
- even with the "magic lever" not thrown, it should be possible for
  users to use the explicit syntax already, e.g. to seek
  [date1;date2]
  and get all values between date1 and date2, /including/ date2

Finally, SQL supports /inclusive/ -- but not /exclusive/! --
date ranges very naturally:

  SELECT ... WHERE DATE(fieldname) BETWEEN date1 AND date2;
  SELECT ... DATE(fieldname) = date1
History
Date User Action Args
2009-07-15 09:18:39tobias-herpsetmessageid: <1247649519.85.0.677124751558.issue1182919@psf.upfronthosting.co.za>
2009-07-15 09:18:39tobias-herpsetrecipients: + tobias-herp, richard, schlatterbeck, ber, ajaksu2
2009-07-15 09:18:39tobias-herplinkissue1182919 messages
2009-07-15 09:18:38tobias-herpcreate