Why are all fields nullable in data classes for views?

[Adam-Langley]

I feel like I've seen this discussed somewhere before, perhaps on on GitHub - but apologies in advance if this is a repeat - I couldn't find the origin.

I have several views defined in .drift files, which are simple views, no joins, yet pretty much all the fields in the Daos (except primary/foreign key fields interestingly) are defined by the code_gen as nullable ('?').

I am wondering why this is?
I could understand if the views contained outer joins (as some of the columns could contain null for rows where no pk/fk match was made) - however that's not the case for my schema.

The effect - essentially - is in my dart code, where I pass the results of these views into my application layers, I need to either pass an default (?? x), or require a value (!). Of course, the bang is technically safe given what I have explained of my schema, but dart trains us to feel gut wrenching nausea whenever we see this... so I'd love to avoid it!
Plus... it means my developers can trust the DAO schema, and not have to know when a bang is safe or not.

Thanks!

[simolus3]

That doesn't sound like the intended behavior. I've checked a few view definitions from examples in this repository and they don't seem to be making everything nullable. Are there any warnings from drift_dev in the build_runner logs?

Do you have a subset of your schema or another example that reproduces this behavior? I can take a look at that to figure out what's going wrong.

[Adam-Langley]

Hi @simolus3 - thanks for responding. Good to hear that I should actually expect non-nullable fields. Let me put together a basic reproduction.
Thanks!