I think mutations on DataObject should all have an input type, rather than dozens of args. So yeah, we need to auto create an input type. You can’t use the object type for that purpose, at least not directly

On a related note: I think we can probably get away with only one input type for create and update. Technically, update shouldn’t allow setting id, but that’ll just lead to input type inflation if we create a new one specifically for update only. We could always move that validation to the resolver

If I have a mutation that has args for ID and NewTitle, I can pass those in individually, or I can just call that PostTitleChangeInput, with those two fields

You mean as opposed to using the object type directly (not creating an input type)?

Basically, we need a way to get the total page count - so if your return value is List<MyObjectType>, there’s no room for it - you need a structure around it

Scaffolding: Should a query or mutation implicitly create an input type if it has > 0 args? Or should that be opt in?

I haven't yet. I'm not sure I quite understand it tbh. I need to read up more on relay.

@unclecheese Did you see my notes on pagination? https://github.com/silverstripe/silverstripe-graphql/issues/7. I don’t think it’ll influence your scaffolding work, but would be good if you sanity check that assumption. Basically, we’ll have a connection type returned instead of a direct list with the actual object type

Attachments:
GitHub  
GraphQL Paginated Asset List Issue #7 silverstripe/silverstripe-graphql GitHub