Would a debounce setting for queries make sense? #460
Replies: 1 comment 1 reply
-
|
Hi @cameronmcefee, sorry for the late response, just seeing this. I think such a tool is probably quite handy, but hard to think of a nice way to include it into the existing tools without things eventually ballooning into a difficult to maintain/document/use Swiss army knife of tools. So, I'm trying to think of alternatives that could be done in user land until we could find some cohesive way to layer this kind of behavior into the library. One idea is that you technically can freeze a query's results in its current state and cut off future observation: $rows = FetchAll(wrappedValue: rows)That puts the current value of $rows.load(Row.all)Also batching together writes is a good choice, because that has the added benefit of not flooding SQLite with a bunch of writes. Those might help get you by for the time being while we think about this problem more generally. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm building a visual-focused RSS app. As images load, I save information about each image to the database. If you're scrolling through a bunch of content, there are potentially a bunch of writes to the database as data comes in, which in turn triggers
@FetchAlland the like to update equally as frequently. However, I don't want the layout to constantly be updating. I'd rather it update in batches, especially if I want to drive it with animation.I realize that one way of approaching this is to debounce the writes, but I'm wondering if there's merit to allowing FetchAll to include a debounce parameter so you could say something to the effect of "update no more than once every 1000ms".
I'm new to databases in general so perhaps I'm looking at this in a naive way. Is this something that would make sense to request as a feature?
Beta Was this translation helpful? Give feedback.
All reactions