Inconsistency in query filtering by Type

Users Dgraph
1

Hi,
We are using Dgraph 1.2.2.

We have a type called Events, with the following definition:

{
  "fields": [
    {
      "name": "Events.EventId"
    },
    {
      "name": "Events.EventGuid"
    },
    {
      "name": "Events.GroupName"
    },
    {
      "name": "Events.TagName"
    },
    {
      "name": "Events.EventClass"
    },
    {
      "name": "Events.EventState"
    },
    {
      "name": "Events.EventPriority"
    },
    {
      "name": "Events.EventValue"
    },
    {
      "name": "Events.EventLimit"
    },
    {
      "name": "Events.ValueString"
    },
    {
      "name": "Events.LimitString"
    },
    {
      "name": "Events.EventTime"
    },
    {
      "name": "Events.EventTimeFracSec"
    },
    {
      "name": "Events.EventTimeZoneOffset"
    },
    {
      "name": "Events.EventDaylightAdjustment"
    },
    {
      "name": "Events.OperatorNode"
    },
    {
      "name": "Events.OperatorName"
    },
    {
      "name": "Events.Comment"
    },
    {
      "name": "Events.OperatorID"
    },
    {
      "name": "Events.EventStamp"
    },
    {
      "name": "Events.new_id"
    }
  ],
  "name": "Events"
}

Executing the following query:

{res(func: has(Events.EventId), first:10 )
  @filter (not type(Events))

        {
          uid
          expand(_all_)
          dgraph.type
        }
    }

and I am getting nodes that are having dgraph.type=“Events”, but NOT returned by the query- for example:

{
        "uid": "0x2580c6",
        "Events.EventStamp": "2014-01-05T09:28:47.813000Z",
        "Events.TagName": "123456",
        "Events.Comment": "3",
        "Events.ValueString": "50.0596",
        "Events.EventTimeFracSec": "8120",
        "Events.EventDaylightAdjustment": "0",
        "Events.OperatorID": 15,
        "Events.EventGuid": "ADCEDF2A3C064D649600966CEEE86770",
        "Events.EventState": "         ",
        "Events.EventPriority": 1,
        "Events.EventLimit": "50.0255",
        "Events.EventValue": "50.0596",
        "Events.OperatorNode": "OEM-73776CC6A82",
        "Events.OperatorName": "JohnD",
        "Events.new_id": "1",
        "Events.EventTime": "2014-01-05T17:28:47.813Z",
        "Events.EventTimeZoneOffset": "-480",
        "Events.EventId": 903413,
        "Events.GroupName": "Manual",
        "Events.EventClass": "EVENT   ",
        "Events.LimitString": "50.0255",
        "dgraph.type": [
          "Events"
        ]
      }

Please advise!
Thank you,
Alon

2

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

4

Hi @alonwein

We have fixed this bug in version 20.03.1, since you are already testing it it would be nice if you can see if the issue still persist on that version (20.03.1)

Best,

5

Hi @omar,
Because it was in consistent, it would be tricky to assess it- but will try.
However we found another inconsistent behavior that is difficult to explain and maybe the root of the problem similar to the original post.
we have two dgraph.type that have the same predicated id and name; id is an index of type integer and both have type definitions on both predicates.
when executing the following, I am getting results only on one type, but not the other- though both have the id mentioned:

{
                    all as count(func: eq(dgraph.type, "class_type"))
                    @filter(eq(id, "11")){
                        total: count(uid)
                    }
                    res(func: uid(all), first: 20, offset: 0)
                    {
                        expand(_all_)
                    }
                }

is it also an issue that was supposed to be fixed in 20.03.1?
Thanks!
Alon

6

Hi @alonwein,

Hard to say if the latter issue has been fixed by that same PR: Always set BlockSize in encoder. by martinmr · Pull Request #5255 · dgraph-io/dgraph · GitHub

I guess the only way to sort it out, is to test it and see if the behaviour is now fixed. Please give it a try on our latest Dgraph version (20.03.3) and if it fails, please provide the dataset so we do the needed tests

Best,