Is it dangerous to return an unpersisted activerrecord with ruby graphql?

Question

In rails, a common pattern I've used is to create a new unpersisted object to populate forms with default values, eg

class ContactsController < ApplicationController
  def new
    @contact = Contact.new
  end
end
...
<%= form_for(@contact) %>

I've created a form using graphql ruby, and I would like to populate the default values using an unpersisted object ie I have a createOrUpdate form populated by contractParts

query Contract($contractId: ID!) {
  contract(id: $contractId) {
    ...contractParts
  }
}
query DefaultContract($ownerId: ID!) {
  defaultContract(ownerId: $ownerId) {
    ...contractParts
  }
}

and in my query_types.rb

  def default_contract(owner_id:)
    owner = Owner.find(owner_id)
    Contract.new(owner: owner)
  end

I'm wondering if this pattern is ok, or if because I'm returning an object without an ID there will be problems. I've looked through all the documentation and I can't find anything about this, is this not proper graphql?

Answer 1

Certainly you can do this. You can create an 'aggregate' of unsaved objects with whatever defaults you like:

 # app/models/default_contract_aggregate.rb
 class DefaultContractAggregate < Contract
   def initialize
     self.rel1 = DefaultRel1.new
     # etc
   end
 end

 # app/graphql/types/query_type.rb
 def default_contract(owner_id:)
   owner = Owner.find(owner_id)
   DefaultContractAggregate.new(owner: owner)
 end

This isn't the worst idea, but of course with graphql, depending on your schema, it would likely be possible to reach the boundary of your aggregate so you'll have to be careful with that. As to your other question, there's nothing inherently wrong with using an unsaved object or having an object with no ID. Do be cautious with associations that autosave on assignment as that can lead to pretty exciting and unexpected results.

Personally, I find that it doesn't take much complexity to outgrow the rails form generators and I prefer to build complex UIs on the front end, but if they're still working for you, there's nothing wrong with continuing to use them.