Daniel Rearden

That's really the crux of the issue -- a lot of the time there's significant overlap between your data models and your GraphQL types... except for the times when there's...

Thanks @TSiege . I like the idea of using TypeScript types too, especially if it means we don't have to rely on graphql-codegen for typing resolvers. But there's still the...

The more I think about it, though, the more redundant and inconvenient this sort of approach looks. A middle of the road approach might be to keep the library mostly...

@JeffML Thanks for your input. Aggregating events like you've described is very clever, and it also conveniently gets around GraphQL [limiting subscriptions to only one root field](http://spec.graphql.org/June2018/#sec-Single-root-field). By necessity, Sqlmancer...

Thanks for the feature request. This would go hand-in-hand with #53 , although offhand I'm not sure what the best approach would be to changing model methods like `findById`. If...

Thanks for opening this issue :) This is something I've also been wrestling with. The core of the problem is that the library currently has no concept of *where* a...

```graphql type Post @model(table: "posts", pk: "id", include: ["id"]) { id: ID! authors: [Author!]! @relate( through: "posts_authors" on: [{ from: "id", to: "post_id" }, { from: "author_id", to: "id" }]...

Thanks for the extensive bug report @DoLevi . I will try to take a look soon.

@JeffML Thanks for all your work on this. I'm sorry I still haven't had a chance to review it -- will do so as soon as possible

Thanks for the quick follow-up. I'm excited to see the spec and would love to contribute in any way I can. I'm also happy to see you're not using the...