SitePen / dgrid

A lightweight, mobile-ready, data-driven, modular grid widget designed for use with dstore
http://dgrid.io/
Other
628 stars 295 forks source link

DStore filter for property equalling null #1374

Closed risoldi closed 7 years ago

risoldi commented 7 years ago

My store has objects representing invoices, with the two following properties:

datepaid either stores a numeric timestamp, or is null (meaning the invoice is not paid).

I am trying to make a Filter giving me all invoices that:

This for me translates to: date < givendate && (datepaid >= givendate || datepaid === null)

In terms of creating the filter I wrote:

new Filter().and(
    new Filter().lt("date", givendate.getTime()),
    new Filter().or(
        new Filter().gte("datepaid", givendate.getTime()),
        new Filter().eq("datepaid", null)
    )
)

This does not seem to work - among the results, I get also some that have date greater than givendate. There are no errors in the console. The filter I get when giving a date of, e.g., May 1st 2017 is:

[
   {
      "type":"and",
      "args":{
         "0":{
            "type":"lt",
            "args":{
               "0":"date",
               "1":1493589600000
            }
         },
         "1":{
            "type":"or",
            "args":{
               "0":{
                  "type":"gte",
                  "args":{
                     "0":"datepaid",
                     "1":1493589600000
                  }
               },
               "1":{
                  "type":"eq",
                  "args":{
                     "0":"datepaid",
                     "1":null
                  }
               }
            }
         }
      }
   }
]

And in the results I get some invoices that have a date of May 4th 2017 (the timestamp being 1493848800000, which is definitely not less than 1493589600000). Any suggestions?

risoldi commented 7 years ago

My bad - didn't notice I was using an older version of dstore. It seems that commit https://github.com/SitePen/dstore/commit/084f92d166c60f6a0c3232c352dd0c3f197123ed solved the issue, that was indeed a bug.