Mikhail Akimov

I'm using https://github.com/Mause/duckdb_engine to build queries, it was just easier to demonstrate directly on the duckdb client, since this is where the exception happens. Here's the code that's closer to...

Let's wait for the author of the dialect, she might know if this is fixable at that level. I'll look into the dialect code in the meantime.

A quick look through the dialect code and sqlalchemy docs revealed that sqlalchemy gets the style for query parameters from the DBAPI driver's `paramstyle` attribute, which is set to `qmark`...

My thoughts: - In the general case, handlers should only apply to the stuff that happens in a paricular node's logic. This is currently tough to do, because calling the...

Are actors stable enough to use? I've been thinking about making something that would continuously maintain the state for some pre-defined computation as new data comes in. Something like differential...

> it seems that calling .flush() rather than .poll() would solve your failure But then, if I call this for each message, latency would be equal to network round-trip time...

But `.poll` should just execute callbacks for new messages delivered to the broker, which should still be delivered even without force-flushing. Why is it slower than calling `.flush`? ```py args...

I think I get it. The source emits the next item only after the future it awaits on is resolved. But it is resolved only once poll is called and...

So `to_kafka.update()` shouldn't return a future, but should retain refs until the callback is called. If there's an error passed to callback, it should retry or raise.

> `to_kafka` also ensures that the order of the messages being delivered to Kafka is preserved I think the client itself doesn't ensure that. It's stated in the docs that...