Open francois opened 4 years ago
To me, the fix seems to be to change this line:
The calls to #belongs_to_and_required?
and #has_one_and_required?
would need to go, leaving only T.nilable(#{assoc_class})
. I can certainly write a PR for that, with specs, but I'm not sure how you want to go about fixing this issue.
There is a class of issues with a newly created or unsaved record (Sale.new
). I'm thinking about how to deal with it, eg we have 2 type: Sale and UnsavedSale. For UnsavedSale, all attributes would be nilable. It's not implemented yet though :-(
Just my 2c on the issue - I think belongs_to
associations with optional: false
should not be nilable as most business logic will be written for when the records have already been persisted to the DB. I personally prefer and think it's less obtrusive to treat calls where the records aren't persisted yet as an edge case than having to handle nilable values unnecessarily. In saying that, if there were a better solution where we could know when those calls would be nilable that'd be amazing
Describe the bug:
ActiveRecord 5.2+ gained the
optional
option onbelongs_to
declarations. sorbet-rails infers thatbelongs_to
relationships whereoptional
isfalse
means that the referenced object will always be present.Steps to reproduce:
In our specific case, we discovered the issue with code such as this:
Expected behavior:
belongs_to
relationships should always beT.nilable(Elem)
, without regards to theoptional
option.Versions: