-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible to generate schema types? #39
Comments
Hello @micimize, how you doing?
You mean generate all types from all the schema, instead of filtering by queries/mutations fragments? I'm not familiar with MoorDB, could you explain your use case? About fragment inheritance & full schema typing, are you talking about having generated classes for the whole schema and queries fragments using them just like your example? How would you deal with non-nullables (I know Artemis can't handle it yet, but I'm asking for future references)?
I was already thinking about somehow exposing the class generation given data classes, allowing custom interceptors/parsers on the generator, defaulting to the current one. Do you think that should be enough to your use case? |
Exactly. Moor is an sqllite lib we're considering building a normalized cache with. So, we'd want to generate a table model per base-type, and normalize operation results into the cache.
Yes - this would let us inherit from the database-connected types, and allow for fragment-like Inheritance. For non-nullables, I don't think it changes anything, we can just use a non-nullable decorator on deserialization On generator customization - that's pretty close, we'd need to be able to define property getters though. An example moor generation: # in
type TodoEntry {
id: Int!
content: String!
targetDate: Datetime
} // out
@DataClassName('TodoEntry')
class TodoEntryTable extends Table {
IntColumn get id => integer()();
TextColumn get content => text()();
DateTimeColumn get targetDate => dateTime().nullable()();
} I think we could collect class names for the database definition itself with |
So you're developing another generator (for Moor) that uses Artemis? Could you point me to the repo? Are you depending on it as a library or as a But yeah, we still need to upgrade Artemis to (optionally) generate the full schema. |
@comigor it's still in the consideration/planning phase - we haven't begun development yet. |
I see. Well, ping me if you try Just two cents from someone who doesn't fully understand MoorDB/graphql-flutter ecosystem, if you're open to this feedbackImplement this cache as an optional & pluggable dependency (even if it's the most recommended cache implementation), instead of having it on the same package. The current implemented caches have a hard dependency to |
Is there a way to generate classes from the base types of a schema? Is this planned?
We'll want to do this for graphql-flutter, and maintain fragment inheritance somehow
Maybe something like this: https://gist.github.com/micimize/ec9df3c1df23f415621fd3da7e81209e
Relatedly, we'll need to be able to customize the generated models if we continue with the moor cache route
The text was updated successfully, but these errors were encountered: