mrjn

14 ms·

121.
by mrjn 6y ago
Discourse prefers a single level threading model, until Reddit or HN. So, you can in fact see all the 7 comments there. Not sure why you only see one.
122.
by mrjn 6y ago
Founder of Dgraph here > But no, you wanted to enforce your graph database which is not proven for production load. One of our customers, a big brand e-commerce site, is running 20 TBs of data on Dgraph. I wonder what makes you claim &qu
123.
by mrjn 6y ago
The existing stored data would stay as it is. It would be automatically converted to datetime on query. The new data that's coming in would be stored as datetime. From user's perspective, the change would be instant.
124.
by mrjn 6y ago
Dgraph supports Subscriptions [1] [1]: https://dgraph.io/docs/graphql/subscriptions/
125.
by mrjn 6y ago
Actually, this is the right page: https://dgraph.io/slash-terms
126.
by mrjn 6y ago
I can never tell if people on HN are joking or being serious.
127.
by mrjn 6y ago
Dgraph doesn't really fit into those descriptions of "RDF graph DB" or "property graph". It's quite a different design. You can read about it here [1]. I think you're talking about facets: [2]. They can be
128.
by mrjn 6y ago
(founder of Dgraph Labs here) This is the policy here: https://dgraph.io/privacy-policy Feel free to reach out if you have any specific questions: contact at dgraph.io.
129.
by mrjn 6y ago
I'd say running and maintaining any distributed system is hard. Which is why cloud makes for an attractive offering for these services, because it lets the provider (Dgraph Labs in this case) ensure that the users are having a great pr
130.
by mrjn 6y ago
Dgraph supports flexible schema. So, you can make a lot of changes to the schema without any "table migration" or downtime. For example, switching from int to datetime to string, adding fields, removing fields, adding relationship
131.
by mrjn 6y ago
(founder of Dgraph Labs here) Hasura is a great product, but it is a GraphQL layer on top of Postgres. So, what you need to do to use Hasura is to first lay out all the tables in Postgres, and then map those table schemas to GraphQL schema.
132.
by mrjn 6y ago
Wao. You describe us as “mad people” because we choose to not use GitHub issues? Is that all it takes to dismiss an open-source software and badmouth its authors? You have gone really low on this. All the issues have been ported over to Dis
133.
GraphQL Tweetletter: A weekly digest of GraphQL tweets(dgraph.io)
2 points by mrjn 6y ago|0 comments
134.
Show HN: GraphQL Tweetletter – Weekly digest of most interesting GraphQL Tweets(tweets.dgraph.io)
5 points by mrjn 6y ago|0 comments
135.
Dgraph is shutting down Slack(dgraph.io)
2 points by mrjn 6y ago|0 comments
136.
Ripping Off the Slack Bandaid(dgraph.io)
3 points by mrjn 6y ago|0 comments
137.
A memo about Slash GraphQL: a managed, production-ready cloud service(discuss.dgraph.io)
2 points by mrjn 6y ago|0 comments
138.
I solved bugs identified by Jepsen in Dgraph: A personal journey(dgraph.io)
3 points by mrjn 6y ago|0 comments
139.
Solving Jepsen with OpenCensus Distributed Tracing(dgraph.io)
97 points by mrjn 6y ago|6 comments
140.
by mrjn 6y ago
Add some producers, cinematographers, actors, oscar awards and so on. Complexity adds up. OTOH, In Dgraph GraphQL, you'd just do a simple schema edit from: type Movie { ... director: Director } to type Movie { ... directors: [Director]
141.
by mrjn 6y ago
Hey Simon, Totally see your perspective. You're already familiar with data migration, but not familiar with graph DBs. The former is just easier to do than to invest in the learning curve involved with the latter. Valid point. My take
142.
by mrjn 6y ago
(author of Dgraph here) There're a bunch of changes you can do in Dgraph, that're very convenient. For e.g., going from 1:1 relationship to 1:many relationships (see my comment about movies and directors). Having sparse data model
143.
by mrjn 6y ago
(author of Dgraph here) I'd argue relational DBs get way more credit than they're worth. And it is indeed tricky to make them work across different data models -- that's by now an established fact across big SV companies. Res
144.
by mrjn 6y ago
(author of Dgraph here) As staticassertion is mentioning, some of the violations that were found were only around tablet moves, which happen only in certain cluster sizes and quite infrequently. Of course, Jepsen triggers those moves left-r
145.
by mrjn 6y ago
v0.7? That was Dec 2016. A lot has changed in 3.5 years.
146.
by mrjn 6y ago
Something is in the works around a managed service!
147.
by mrjn 6y ago
Sentiments are changing now, particularly with GraphQL. Dgraph bet on GraphQL early on, and it's really catching on as a replacement for REST.
148.
by mrjn 6y ago
Dgraph | Community, Distributed System and Frontend Engineers | Palo Alto, Bangalore, Remote | Full-time | https://dgraph.io/careers Dgraph is looking for Community Engineer (top priority), Distributed System Engineers and
149.
by mrjn 6y ago
No worries at all, I like to hear feedback from users, whether its positive or negative. Though, I also like to separate wheat from chaff, which is why I have suggestions / follow up questions, etc. Assign endpoint is something that yo
150.
by mrjn 6y ago
We now have a dedicated technical writer on the team, whose sole job is to improve our technical documentation. If you have suggestions, would be great if you could jot them down at [1], so we can improve the documentation. [1]: https:&#x2

More ›