Are there any commands to get overall data info


(Fengchang) #1

I’m new to dgraph, when using relational db like mysql, there are some commands like ‘show databases’ , ‘use database’, ‘show tables’, ‘select * from table’ etc. these commands give me a very clear view of what the current db has, and provide hierachichal isolation of data nice and clear.
but coming to dgraph, let’s say I want to see what I have all in dgraph, or I happend to import the sample data twice, I need a clear view of what I have in dgraph at the moment. But I can’t find anything like that in the tour document, it seems it just ignore that problem which I think is very weird.
If dgraph is designed that way, there must be a reason right?


(Michel Conrado) #2

Well, on “show databases” it runs away from the Dgraph concept. Dgraph does not have multiple DBs, it is DB itself (BadgerDB).

The concept of tables is also very different from wich is used in the Graph database.

“select * from table” could be something analogue to “expand (all)” with this function you can infinitely expand a query.

Example:


{
  jeunet(func: allofterms(name@en, "Jean-Pierre Jeunet")) {
    uid
   expand(_all_)
  }
}

The best way you can visualize is by using Ratel. And to use it the way you want, you then need to build queries according to building your business logic. And then use “expand (all)” inside each query block.

With “expand (_all_)” you can do so too to explore more that relations:

{
  jeunet(func: allofterms(name@en, "Jean-Pierre Jeunet")) {
    uid
   expand(_all_) { 
        expand(_all_){
              expand(_all_)
              }
       }
  }
}

Through Ratel you can visually see the relationships of the Nodes and also see your Schema and even modify it.

If you want to do some manual things that Ratel does, just look at these Docs.

https://docs.dgraph.io/query-language#querying-schema
https://docs.dgraph.io/query-language#expand-predicates


(Fengchang) #3

thanks for your answer, but the example you posted here still need some prio knowledge, you need to know at least there is one node named “Jean-Pierre Jeunet” right? it’s more like traverse the whole db from a given starting node, but what if I don’t have any prior knowlege of what I have in the db. the only thing I can think of is to use the
schema{}
command first, and then maybe pick a uid and do what you posted, even that I still need the assumption that the graph is a connected graph otherwise I won’t be able to reach every node, am I right?


(Michel Conrado) #4

Not exactly. Dgraph is doing a search. In this case he looks for all terms that have “Jean-Pierre” and “Jeunet”. That are recorded in English (name @ en). But surely anyone who is “searching” has to have an idea of what to look for.

Actually Dgraph indexes according to what you request. So he’s just going to dig that corner of the index. Generally to search by term you should index like this

name: string @index (exact, term).

This line sets the indexing to “exact” and “term”.
But of course, you must learn to use indexing in your favor. More on that here. https://docs.dgraph.io/query-language/#indexing

As I said earlier, you do not have to assume anything. You are just searching. The only thing that DB admins should do is plan the indexing and a query pattern.

With the schema {} query, you will only receive the schema format. There will not even come a UID. Because this query does not look for Nodes.

Dgraph is a DB based on GraphQL. Whoever understands GraphQL will do well with Dgraph. As Dgraph uses the “logic” of GraphQL plus the mathematical concept of graphs makes it a little strange for people who came from old standard databases like SQL.

The only thing you need to care on is the predicate. And you can do this by Querying Schema. After that, you will build your default query to request what you want. Using Ratel you can get a good build of Queries. It predicts possible predicates that you will use.

Let’s say you found a predicate called “party” When you Queried for Schema.

{
  allMyDesiredParties(func: allofterms(party, "Rock in Rio")) {
    uid
   expand(_all_) {expand(_all_)} 
# using expand(_all_) you do not have to worry about having prior knowledge of anything. 
# Dgraph will expand until you can find no more connection between nodes ..
  }
}

You will build your query thinking how it was indexed. If it has not been indexed Dgraph will not return to you. It will show an error of type “This predicate has no indexing”.

So it’s important to pay attention to Schema and indexing. To build your application.

If you have a predicate that has not been indexed. You can use “Has (some_predicate)” to collect Nodes with this predicate. For example.

{
  Data_2018(func: has(predicate)) {
    uid
   expand(_all_) {
       expand(_all_)
    } 
  }
}

(Fengchang) #5

thanks for the long and detail answer, maybe I should learn some GraphQL first, here’s a quick question, is there anyway to use ratel to visualize ALL data in current db? since there is no counterpart as select * from table in mysql.


(Michel Conrado) #6

For now there is no way to visualize what we have in total within the Database. It is necessary to build queries already focused on the current use of the database. That is the only way to visualize.

Maybe in the near future we will focus on a feature like “introspection” (https://graphql.org/learn/introspection/) but this will require serious changes in language and DB. Dgraph although inspired is different because it is a DB itself and not just a communication layer as in the case of GraphQL.

Most Dgraph engineers are focused on other situations. If someone in the community can help and is interested in this feature. Just open a PR.


(Fengchang) #7

thanks, great answers, cleared many of my doubts, hope dgraph getting better and better for production use(づ ̄ 3 ̄)づ


(Srinath Ganesh) #8

Valid point but for a use-case: if someone wanted all the nodes of type People without knowing a single persons name, that’s not feasible?

Something equivalent to
neo4j cypher> MATCH (p:People) RETURN p
gramlin> g.V().hasLabel(“People”)


(Michel Conrado) #9

Well, if you want to return all users. It could be done in two ways.
By looking for a predicate that only exists in the user’s Node or
creating a special predicate for the user registry.

{
  q(func: has(name)) {
   uid
   expand(_all_)
  }
}

The second approach would be with https://docs.dgraph.io/howto/#giving-nodes-a-type

{
  q(func: has(_user)) {
   uid
   expand(_all_)
  }
}

example of other kind of node.

{
  q(func: has(_board)) {
   uid
   expand(_all_)
  }
}

ps: But you could use another approach, like creating a type predicate and indexing by hash, but it’s best to use Kinds as presented.


(Andro West) #10

This seems worked on version v1.1.0

{
  showallnodes(func: has(dgraph.type)){
    dgraph.type
    expand(_all_)
  }
}