Predicate in a Go struct and uid is now string?

Users
1

What would a predicate in a Go struct be?
Because
https://docs.dgraph.io/howto/#giving-nodes-a-type

I’m not a native English speaker and I never had to learn a different language using those words.

For a

type Community struct {
}

would the predicate be

type Community struct {
IsCommunity bool `json:"-"`
}

?
Oh and do I have to index it?

And from your client example with SetObject
https://godoc.org/github.com/dgraph-io/dgraph/client#ex-package--SetObject

You have uid string
Did the native type of uid change from int64 to string?
Do I have to set the value of uid when I insert a new … object?

2

Hey @dalu

From the SetObject example

type Person struct {
    Uid      string     `json:"uid,omitempty"`
    Name     string     `json:"name,omitempty"`
    Age      int        `json:"age,omitempty"`
    Dob      *time.Time `json:"dob,omitempty"`
    Married  bool       `json:"married,omitempty"`
}

The predicates would be name, age, dob, married. They are analogous to column names in a SQL DB.

For your example, you should have something like below in which case is_community would be a predicate.

type Community struct {
  IsCommunity bool `json:"is_community"`
}

That depends on the kind of queries you want to perform. If you just wanted to retrieve them then you don’t need any indexes, on the other hand if you wanted to perform an eq query then you would need some index.

Internally, uid is stored as a uint64 but for the user its a string. You give us a string and we return a string.

No, you only set the value of uid when you want to update something. In other words, if the marshalled object has a uid field, we assume its an update otherwise we create a new node.

3

Late reply, busy sorry and computer died etc.
Anyhow,
In the context of the question (giving nodes a type, see OP) I’d filter by “has predicate is_community”
Would I need to index this predicate in this use case?

And I know it’s hard to predict the future, however maybe you have a plan.
Do you expect the way inserts, updates, queries and deletes are done to change?
aka. if I wrote a http api with dgraph as storage how likely is it that I’d have to rewrite both the app and the way I do CRUD once 1.0 is out?

Regarding uint64 id, if I understood correctly,
When I do

p := new(Person)
p.Uid = bson.NewObjectId().Hex()

this would be the unique identifier and not an uint64 value.
An uint64 value would only be assigned when .pUid == “” and then this value would be converted to string when querying.
I’m still concerned about the value overflowing.
uint64 maybe large but it’s not that large when every transaction, every query receive their own uint64 id( that seems to be serial).
Imagine a semi busy social network/dating site with 10k members all uploading fotos and sending messages and doing queries and searches

4

I’d filter by “has predicate is_community”. Would I need to index this predicate in this use case?

An index isn’t needed in this case (it used to be a few versions back, but isn’t needed any more).

Do you expect the way inserts, updates, queries and deletes are done to change?
aka. if I wrote a http api with dgraph as storage how likely is it that I’d have to rewrite both the app and the way I do CRUD once 1.0 is out?

We expect this to remain stable from now on (we plan to release 1.0 very soon).

I’m still concerned about the value overflowing.

Don’t worry, uint64s are pretty big. If you were to continually assign 1 million UIDs per second (which is absolutely crazy!), then the range of a uint64 will still last you for almost 60,000 years.

5

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