Drift queries result objects - enhancing the PODO (plain old dart object)

[Adam-Langley]

I use BLoC, and I need my view state to refresh when the underlying database entity has changed.

I achieve this by mapping the drift entity to a view model class using a simple toJson/fromJson operation - this is possible because drift Table and View results implement json serialization.
My view model class then uses Equatable to ensure all fields are considered during equality comparisons.

It's nice and simple.

i.e. var model = ModelType.fromJson(entity.toJson())

I have started to use .drift queries to shape the data more before mapping it to a viewmodel - however I have hit a roadblock - while drift tables implement toJson to extract a simple field dict - query result classes generated by drift queries do not.

So I guess I have a couple of questions:

1. could I request that these view classes are enhanced in such a way to meet this need? One idea could be to simply generate the toJson function for them the same as the table and view results do.
2. It's actually possible I could entirely forego my entity->model mapping process, and just use the query result entities in my BLoC state, however to support this, I need the view entity to account for its fields in the equality operator overload - i.e. Equatable - this would be the ideal solution really.

Thoughts?

[simolus3]

The JSON trick is not something I'm super happy with - it sounds like something that could break quietly (and IMO, adding serialization to generated row classes was a mistake - it's convenient, but terrible for separation of concerns).

and just use the query result entities in my BLoC state, however to support this, I need the view entity to account for its fields in the equality operator overload

You can enable the override_hash_and_equals_in_result_sets builder option to have drift override equals in classes generated for queries.

But since drift can map both tables and result sets into existing row classes, I wonder if you can use the view models you already have and let drift map rows into those instead? If you're already writing model classes with the features you need, letting drift use them as well feels like the cleanest solution.

[Adam-Langley]

Thanks @simolus3 - I think you're probably right about the json mapping. It worked, but was blind to changes in field names - risky.
I'll look into your suggestion.