inefficient store_event behavior for sets/tables about broker HOT 5 OPEN

Adding those operations seems like the right direction, but as long there's a no urgent need I'd leave that for later and turn this into a corresponding feature ticket.

from broker.

This probably also is not really urgent. For the feature I am implementing, trying to put tables into broker tables probably was a bad idea and made the code way more complex than necessary. So - I don't actually use this case anymore.

Also, thinking about this more - this actually might be more complex than I thought about at first - because in some circumstances the current behavior might be the behavior that one wants.

from broker.

I think implementing this would be somewhat straightforward, but would require changes to (all) backends. The current interface only provides a put function that sets the entire table as a single value. We only have special functions for adding and subtracting integer values. That being said, using the topics for identifying rows probably gives the same result with the current API as long as the tables I have a fixed layout (which is probably what you are doing?).

from broker.

Is this something we'd still want? We could revisit this after merging #201. Or just close it outright if we no longer think we're going to need it.

from broker.

I'd leave it on the wish list for now: would be a good change, but not higher priority than some of the other pieces currentky in the queue.

from broker.