Optional strong ref about streamz HOT 7 CLOSED

Yes, that is possible. To decide if this is something that we should do it would be useful to understand the costs and benefits of such a decision.

from streamz.

I guess my current issue is that we are optimizing the execution graph based off of sinks, but some of the other nodes may do things that effect the system overall but are not sinks. Eg a map which saves something to a database or writes out some file. Currently that node would be removed if it isn't attached to a sink.

I guess one could argue that that function should be split into two parts, the first which does computation and the second which sinks to a database but to some extent we may want to meet users where they are and encourage changes without causing breakage.

This does make some things a bit more complex as the user will need to understand the difference between strong and weak ref'ed nodes, but that may be ok as it will nudge users towards the weak ref workflow while giving them a safety release valve for the short term. It will also increase our complexity some, but maybe not in a truly awful way (I don't know what this means implementation wise yet)?

Maybe another workflow is to have a dummy sink and attach it to things that we care about?

from streamz.

Two cheap options come to mind that don't require changing the codebase.

1. Replace map with sink in your code
2. Create a keep function that registers your stream to a global set

_kept_streams = set()

keep = _kept_streams.add

keep(source.map(func))

from streamz.

I like option 2, thank you!

from streamz.

Great. OK to close then?

from streamz.

Out of curiosity, what is the aversion to using sink?

from streamz.

Sink and map mean different things in SHED and I've inherited the weak ref system from streamz. In this case map dispatches between the different document types (start, event, etc.) whereas sink just passes the documents to the callable (which has to handle the heterogeneity itself).

from streamz.