How to properly do filtering


(Labs) #1

Hi. I’m having a very, very bad time with DGraph, now that it comes to extract information from it.

I’m kind a terrified too, as deadlines are coming crushing over my head.

Lets go to the case:

  • I have an issues control
  • An issue has a category (relationship)
  • An issue can have one or many tags (relationship)
  • An issue has an author (relationship)
  • An issue can have one or more participants (relationship)
  • An issue can be from one customer (relationship)
  • An issue can be linked to a specific customer department (relationship)

Now, I think thats a good case for a graph db, right? Ok, lets go filter.

The user wants to filter all issues:

  • In a period
  • AND filtered by category “A”, “B” and “E” << NOT “C” NOR “D”
  • AND filtered by tags “T1”, “T4”, “T8” << NOT ANY OTHER TAG
  • AND that belongs to “CustomerX”
  • AND that be specific to the department “SALES” or “ACCOUNT”
  • AND the result should be ordered by creation date

Its a classic compound filter panel where the user tick on checkboxes and the interface refresh the data by combining the user demand to filter the data.

I am now too [dumb | stupid | nervous] to accomplish that.

Can anyone please point me to docs with real life examples (not shallow queries) or point me to examples on how to achieve that?

Any help will be much appreciated.

Thanks.


(Labs) #2

Please keep in mind that the user is presented with a panel where he can click a button and add “CustomerY” and “CustomerZ” at any time he wants, as well add or remove tags or categories in the equation, and obviously all of those tags, categories and customers are feeded by the user while using the app, so I dont know at “query write time” wich tag / categ may be in the database.


(Michel Conrado (Support Engineer)) #3

Sorry, but there is nothing in the docs or tour close to your personal project. The most I/we can do is try to work out something approximate to your ideal. But it can take time.

But by looking of it, it does not seem to me that complicated. It just needs planning (preferably in visually) and hand to work.

Have you cross the whole Dgraph’s material and still lost? Can you provide a feedback about this? pls. So we can improve our materials.

I’ll work on something, but need time.

Cheers.


(Labs) #4

Hi @MichelDiz. Thanks again for your support.

Yes, I’ve been reading and studing what I can. I saw the Stack Overflow port, I took the tour a couple of time (its broken on query vars, btw) and still having a hard time on extracting information.

I think that what my project presents its a very normal M:n:M data app scenario, and represents a real case of filtering / grouping / sorting needs that is not in any case over the top. I a real app, the user will demand to cross filter things only ALL the time.

I’m aware at this point that DGraph let some things to done on the programing side “by design”, and I’m totally OK with dynamically build queries, but a completely different thing is to have to traverse and do grouping and joining by hand from several query endpoints results and then have to apply some sorting over it to complete the task before send the result to client.

This is not developers job, its a db engine job.

I’m coding some procedures to deal with, and reducing a little the interface scope to beat the deadline, until I have more time to study, so, take your time and if you guys came with anything, I’m all ears.

Please, do forgive me guys if I’m just missing things here. I still think this is a great product and I’m eager to see it trough. If I could be of any help, please let me know.

And any help on my side is still very welcome.

Thanks.


(Michel Conrado (Support Engineer)) #5

I’ll check, also @shanea has been checking for those lately.

For sure. Are you alone on this project?

I’ve started to work an example. First visually, then queries and mutations.


(Labs) #6

Here is an quick example of the structure in JSON:

let issues = [
    {
        __is_issie: true,
        desc: 'An issue',
        
        author: [
            {
                name: 'bob',
                emails: [
                    {
                        email: 'bob@somewhere.com'
                    }
                ]
            }
        ],
        
        categories: [
            {
                __is_categ: true,
                __is_classificator: true,
                desc: 'Problem'
            }
        ],
        
        tags: [
            {
                __is_tag: true,
                __is_classificator: true,
                desc: 'Urgent'
            },
            {
                __is_tag: true,
                __is_classificator: true,
                desc: 'Bug'
            },
        ],

        participants:[
            {
                name: 'joe',
                emails: [
                    {
                        email: 'joe@somewhere.com'
                    }
                ]
            },
            {
                name: 'mary',
                emails: [
                    {
                        email: 'mary@somewhere.com'
                    }
                ]
            }
        ],
        customer: [
            {
                name: 'CustomerX',
                department: [
                    {
                        dept: 'Account',
                        incharge: [
                            {
                                name: 'bob',
                                emails: [
                                    {
                                        email: 'bob@somewhere.com'
                                    }
                                ]
                            }
                        ]
                    }
                ]
            }
        ]
    }
]

(Michel Conrado (Support Engineer)) #7

It’s almost done, I did a gist for that example.

ps; I noticed some difficulties (Which I believe can actually confuse people.), but this happens because of uid_in. If it were more dynamic, it would all be easier. I will propose changes for this function tho.

In addition to sorting categories and tags by Nodes, I’ve added a few examples with List Type https://docs.dgraph.io/query-language#list-type. That may be interesting to you. See the queries with the name of “metatag” (do not care that much for the names)

Btw I put some comments and descriptions in the queries and also in JSON, just to remember.

First use run the schema, then the mutation and explore it.
But Check the JSON structure before anything.

I did it in a simple way so we could talk. I’ve been doing this for a while, see what you think.

It’s not ready yet, it needs polishing, but look it over.

Cheers.


(Labs) #8

Well, if thats not a 5 star support, I dont know what else is… =]

I will take a look into it first thing tomorrow morning and will reply back to you, ok?

Thanks man, you are the best!


(Labs) #9

Hi, @MichelDiz.

Had too little time to work your gists out, but did some tests. I’m getting the overall idea and realize better the whole datetime schema.

Seems to me that the goal is to build a datetime network as you go, and traverse that instead doing datetime “arithmetics” to group and filter things.

I’ll do some more tests at lunch time and during the hollydays and will post updates, ok?

But I think we’re going somewhere. Looking good.

Thanks again.


(Labs) #10

Hi, @MichelDiz.

Im using some of your suggestion and with some struggle, being able to pull it off.

All in all, looks to me that if some pivot things had slight another behavior, life would be a breeze with dgraph.

After my release date I’ll post here my thoughts about it ok.

Thanks again.