flowOf doesn't respect the passed key.

[Kasheen]

Summary
I realise this is currently an undocumented feature but I think I've encountered a bug with the flowOf function in DBImpl.

Specifically line 38 doesn't take into account the key that the user passed to the function.

One would expect to only receive flow emissions for the model which relates to the passed key, but instead you get everything for that model type.

Fix Proposal
I think trySend at line 38 needs to be guarded with if (keyFrom(operation.model).equals(key)) { trySend(operation.model) }

Other thoughts
If you want me to provide reproducible code or a pull request for the fix I can do - or perhaps I'm misusing the feature.

It looks like the bug would affect the stateFlowOfId function as well because of the delegated function calls.

My current workaround is just to filter the resulting flow and check if the model's id is the id I actually want.

Ultimately it also seems useful to have a function which makes a flow that takes no key which can then be filtered differently and collected in case a user doesn't want to make a flow per id, but currently passing a key feels like it should filter.

[Kasheen]

Just another thought about this. It seems like key is doubling up its role when init is true so that it can put out an initial value. That seems fine when you're listening to one specific id, but over the whole collection doesn't make much sense to me, and I don't think that functionality is available in the regular register function. Perhaps this got added to make the stateFlowOf listeners work properly?

[SalomonBrys]

This is embarassing.
You're right, the key should be checked in the listener.

Also, yeah, init exists specifically for StateFlow.

If you can put together a pull request, I would be glad. I am currently working on a rewrite of the engine to add more typing ;)

[horatiu-udrea]

My current workaround is just to filter the resulting flow and check if the model's id is the id I actually want.

Sadly this does not work for me since I also need to get null whenever the model is deleted, and of course null does not hold the key.

@SalomonBrys, can you have a look at @Kasheen's PR when you get the chance?

By the way, I really like the library, nice work!

[Kasheen]

@Halex193 Sorry for the slow reply on this one, been a little busy!

It's been a little while since I wrote that PR, but I also remembered thinking at the time that there might be another work around when it came to deleted models which was to use the operationFlow, I have a feeling that gave you more than just the model back in the flow, I think it perhaps gives operation and maybe a key (which would hopefully allow you to determine which model).

If you check out the more up to date docs on github here you might find something that helps you with regards to null models coming in through the regular flow.

Sorry I haven't tested anything I've said in this message but I wanted to write this reply because I saw your comment a few days ago.

[horatiu-udrea]

@Kasheen thank you for taking the time to respond, it is thanks to people like you that open source projects are evolving so much!

I have analyzed my needs and ended up going for a more low-level solution, using other libraries.

I really like the direction that this library is going, and I would like to see it stable in the future! Maybe I will contribute myself if I get the chance.

[Kasheen]

@Halex193 Thanks, but just to clarify incase there's any confusion - I'm not a maintainer, just a fellow user such as yourself who wrote a bug report and tried to fix it.

Just thought I'd reply to your original question incase I could be of help.

[horatiu-udrea]

@Kasheen I know, that is why your time investment is valuable