We’re going to start releasing prototypes and mocks on the features that are important to you. The first feature is a data explorer. This mock is definitely an MVP and we already have a lot more ideas for functionality that we want to add but we want to get something out quickly that works.
So please scroll to the second page of this Ratel prototype and click on the node labels. Once the graph appears the nodes are also clickable.
We’d love to get your feedback by:
Think about the questions you ask yourself when you are working with Dgraph. Will you be able to follow this flow and get to the answers you are looking for?
If not, what are the questions you are looking to answer?
What is still missing?
In your exploration, does the data table that is split screen with the graph helpful, harmful or does nothing for your ability to explore the data?
In my opinion we should able to do following basic thing
Filter with different attribute (like age >= 18)
There maybe three input box, one for attribute (age), one for operation (>=) and last one for value(18)
Sort the result (like, order by age ASC)
One input box for attribute and another select box for ASC or DESC
Limit the result (like, from 0 to 100, from 200 to 500 etc) as graph may ave millions of edges
With two number input box one for from and another for to.
When we hover over the node or edge of graph we should able to see the data related to that node or edge.
Export option so that we could able to import another developer machine.
Yes, it will help.
One concern is about graph, it can have many nodes. So if we have collapsible button so that we can hide or show the data table as required will be much easy to explore.
@vespertilian This totally makes sense but I’d like to be crystal clear on what you are thinking and how you plan on using this. Could you walk me through the experience you are thinking or what problem is this feature solving for you?
But it would be convenient for me if I could just click on a listed predicate and have a base query setup from this root predicate, instead of copy pasting from my gist.
Also you could limit my options to what is available based on this root predicates type.
Adding operations like Alter an mutate which I use less would be helpful as well.
hi , I want a query template manager. looks like bookmarks .
because it’s often a continue trying way to get the final right query.
I often need find the last right query from history . If I tried many times, it’s hard to find it in too many history query records.
now ,What I am doing is .
I copy the query I need to a text file . and switch to Ratel ,if I need find my last right query ,I switch
back and copy it to Ratel.
Did I make it clear?
for example:
I write a query
{ allFriends(func: uid(0x1){ friend}}
I want to reuse it later.
If I can save it as a template and give it a name “allFriendTemplate”
then, when I need it , I right click with mouse, and select a menu paste from template
and select allFriendTemplate, then the content of the template { allFriends(func: uid(0x1){ friend}} will insert behind the cursor pointer.
Please change the layout to side by side panels, left to write queries, right to see results, or better, keep the existing model, and add this new one.
A drag to change width of the side by side panels would be a nice plus.
Did I make it clear?