Skip to content
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

Open
micimize opened this issue Oct 6, 2019 · 5 comments
Open

Possible to generate schema types? #39

micimize opened this issue Oct 6, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@micimize
Copy link

micimize commented Oct 6, 2019

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
// base type
class Foo {
  String _foo;
  int _bar;
}

//fragment exposing foo
class FooFragment extends Foo {
  String get foo => _foo;
  set foo(String value) => _foo = value;

  FooFragment({String foo}) {
    this.foo = foo;
  }
}

Relatedly, we'll need to be able to customize the generated models if we continue with the moor cache route

@comigor
Copy link
Owner

comigor commented Oct 7, 2019

Hello @micimize, how you doing?

Is there a way to generate classes from the base types of a schema? Is this planned?

You mean generate all types from all the schema, instead of filtering by queries/mutations fragments?
That's actually what Artemis used to do before v0.2.0, but I felt it was really not useful, so I've dropped it in favor of fields needed by the query alone.

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)?

Relatedly, we'll need to be able to customize the generated models if we continue with the moor cache route

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?

@comigor comigor added the question Further information is requested label Oct 7, 2019
@micimize
Copy link
Author

micimize commented Oct 7, 2019

You mean generate all types from all the schema, instead of filtering by queries/mutations fragments?

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.

are you talking about having generated classes for the whole schema and queries fragments using them just like your example?

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 OnNewClassFoundCallback.

@comigor
Copy link
Owner

comigor commented Oct 7, 2019

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 build dependency? GraphQLQueryBuilder currently implements a callback of parsed data which I primarily use for testing, but I think you can use instead of OnNewClassFoundCallback, making it easier to generate your own classes after Artemis parsing.

But yeah, we still need to upgrade Artemis to (optionally) generate the full schema.

@comigor comigor added enhancement New feature or request and removed question Further information is requested labels Oct 7, 2019
@micimize
Copy link
Author

micimize commented Oct 7, 2019

@comigor it's still in the consideration/planning phase - we haven't begun development yet.

@comigor
Copy link
Owner

comigor commented Oct 7, 2019

I see. Well, ping me if you try OnBuildQuery/OnNewClassFoundCallback. I'll see if it's easy to generate the whole schema again.

Just two cents from someone who doesn't fully understand MoorDB/graphql-flutter ecosystem, if you're open to this feedback

Implement 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 path_provider, which makes usage on flutter web more difficult, for instance. IMO everything should be as pure as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants