New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
return_initial
#3579
Comments
I wouldn't worry about this for 1.16. Moving to subsequent. |
Agree with @danielmewes. I do think that once 1.16 is out, |
I would be interested in seeing this implemented. |
Sounds good, thanks for the update @danielmewes! |
This is in |
Thanks for the update, @mlucy! |
If I understand this issue correctly it will allow the results of a table be gotten initially and watched ala point changefeeds? I would/will use this feature. -- Edit |
I think that all types of changefeeds should either default to returning initial changes, or not. The mixed behavior that we seem to be adopting is confusing. I see the logic in where the defaults are, and especially in having |
I can definitely see where you're coming from, but I disagree with the conclusion (that we should standardize on one default). It feels like:
Given that we're picking between different evils, I think we should go the pragmatic route (different defaults in different cases, accept the inconsistency) and document it really well. But I can definitely see why people are unhappy with that behavior. I'm unhappy with it too, just less unhappy than the alternatives. |
I think there's a difference though because the first is bad because you'll accidentally suck down your entire table. The second one is bad because it's a bit annoying to need to tack on "return_initial" when you almost always need to for that kind of query. But! That's only because we support changefeeds on a limited subset of queries right now, and mentally we're translating If you still aren't convinced, think about the costs of the second in terms of annoyance to the user. They're going to reason out naturally "Ok, I want to get these users, and order them... then I guess I'll take the top 3. Ok changefeed that." then a bit later "Oh whoops, I need the initial values. Do I need to do a separate query to get the initial values? [reads docs a bit] Ah, neat, there's an optarg that will give them to me". My contention being that instead of looking up in a big list of changefeedable queries "Which one gets me a leaderboard?", they're likely to reason it out for themselves, and in that case, they'll appreciate the regularity of |
That's a pretty compelling argument to turn it off by default. |
I think I agree with that. ...Unless there's some very clear and generic distinction between the two cases that I'm not seeing. |
I agree. The consistency is actually a big win here. Furthermore this problem could still be solved via root level defaults configuration (e.g. let users customize/toggle what the defaults are etc.) if we really wanted to. |
Alright, let's turn it off by default for everything in 2.2. We may want to pick a shorter name. The current name is |
|
Shouldn't this be |
Sorry to drag on the discussion for forever, but what do people think about a really short one like If people don't like a short one, I think |
I prefer short names in general, but |
I agree with @deontologician. |
I agree with @deontologician as well. |
Alright, |
👏 |
Sounds great |
👍 |
commenting to register my interest in this issue publicly, as well as subscribe for further updates |
+1 |
When this feature is added, will it dissolve the differences between 'point' changefeeds and other changefeeds? |
@danielcompton -- yes, the interface should be the same. |
This seems very promising, I guess the 2.2 release is months away? |
@stellanhaglund -- we don't have a release date yet, but we just released 2.1 and historically releases have been 1-3 months apart. |
Question: would the initial state stream be possible to sort? |
@tatsujin1 If you just do an There are two work-arounds:
The reason for why unlimited changefeeds with |
Thanks for the thorough response! That changes arrive amongst initial state documents is not a problem; the two sets are simple to serialize in application code. Hmm... come to think of it, I'm not sure that is strictly required. :) (especially as the initial is sent first, as you mentioned) Sorting the initial state is something I need, however; the inter-document arrival order has meaning in my case, e.g. A then B means X; B then A means Y. But hey, I hadn't thought of using an indexed Yeah, I know of the |
This is in |
We never implemented a
return_initial
optarg. Currently point changefeeds and limit changefeeds always doreturn_initial
, and other feeds never do. I think that's probably the desired default behavior.It would be too much work to support
return_initial
on range changefeeds before the release, but we could offer the option to disable it on changefeeds where it's enabled by default. @coffeemug, @danielmewes, do you think this is worth doing?The text was updated successfully, but these errors were encountered: