Support for composite primary keys

[jdgamble555 (Jonathan Gamble)]

This is one of the several standard features that SQL supports that DGraph doesn’t. For now, one work around is to do something like this:

type Node {
  id: String!
  version: String!
  composite: String! @id
}

Add the composite string as id__version so that it is forced to be unique. You could use a lambda to enforce this, although if you add it correctly, it will be be unique without a lambda.

Composite @id fields

Hi, will this RFC also include composite indexes? E.g. in this example I want to allow unique names within a group of bars, i.e. the uniqueness should only be validated for the composite pair (fooID, name). type Foo { id: String! @id bars: [Bar!]! } type Bar @id(fooId, name) { fooId: String! name: String! }

Support multiple unique fields in dgraph GraphQL

@rajas I just wanted to give an example of a perfect use case for this. While you are building graphql facets, there is a need for this in basic graphs. Let’s say a user reviews a movie, there should be only one review: Obviously, it would be better to have a unique restraint like in SQL: ALTER TABLE `Rating` ADD UNIQUE `unique_index`(`user`, `movie`); J

Support composite indexes

aperotte commented : One way to get something similar to composite indexes is to allow indexes on facets. This would be a sort of composite index on the (edge, facet) combination. It wouldn’t be as general as full composite indexes but it seems like this approach would also work well with the idea of sharding by predicate (along with its indexes).

J