is there a better way to check if a flow is emtpy then,

flow.count() == 0 ?

Flow is lazy and cold, there is no way to know how many elements are there until you start consuming it and consume all elements, so there is no other way, it in general look as not a correct approach

have a connection from webflux (spring) to cosmos db and this returns a Flow<T> but if there are no elements i want to throw a custum exception from the backend and not an emtpy list (cause i am returning an APPLICATION_JSON)

but if there are no elements

But Flow<T> from database is not a container for list of elements, it probably a stream of updates of database

like suspend fun : List<T> instead of fun : Flow<T> ?

yes, like suspend for List

yeah ll complete

if it does, it’s quite strange, but then you should do just this: val t = flow.toList() t.size() == 0

Shouldn’t in webflux you do this: select().blah.fetch().awaitOneOrNull()

so it looks that webflux really asyncronously request all items

yeah this is exactly what happens under the hood => return as whole json

yeah, but I quite surprised that such explicit behaviour is possible to achive only implicitly assuming how Flow<T> or Flux<T> is implemented under the hood

so far its working quite nice

my problem with count() == 0 is that you anyway need data, count() consumes flow, so if you do this, it would be incorrect:

fun getData(): Flow<T> {
  require(flow.count() > 0) { “DB is empty }
  // at this monent DB is changed, items deleted
  return flow // you still have to request flow again
}
```

cool i am gonna try this approach

whats the downside of always converting to a list and throwing if its empty?

Yeah, I think it what you need exactly, and very reactive, but still a bit strange for me, suspend List<T> is what actually needed and it has nothing to do with blocking code

yeah, if the normal path is converting it to a list at some point thats where it should throw

I’m just worry about such approach in general, you received some Flow<T>, if your code has no option as get all items, it becomes dangerous, if someone changes upstream implementation and it will never complete In such cases more safe probably to have some timeouts when you collecting data to avoid forever suspended code, which, same as deadlock, is very nasty bug and hard to debug So provide a clear API to receive List of data looks as good solution, and let user decide, use List<T> or Flow<T> depending on case

I think you want to return Flow<User> because some database drivers can read 1 row at a time lazily

yes, this what I meant by optimisations, that it supported on level of DB driver, it actually pretty cool, but if you application sends all results together, something like HTTP, and not some streaming socket, this lazy select will not help and probably will be a bit slower

true Andrey

in htttp you can stream the reply and even if you don’t you can start to build the reply while data is still coming in.

which not necessary always possible (like case an error for 0 elements) and not always faster, especially if building the reply is not heavy operation

even if you just want to build a json string from a list of replies you can avoid creating an immediate List

it’s true