You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the estimated size is exposed (see #1229), we should also allow users to use it in checkVersion instead of the record count. The size could, in theory, be more useful on record stores that don't have an appropriate index (or for whom executing a query against the index is too costly).
I think there's a way to make this backwards compatible. At some point, we may want to make using the size the default. However, there are also some unknowns about the performance of this on large stores, so until we know that for sure, I think it should be opt-in.
To make this backwards compatible, I propose adding a new method to the UserVersionChecker that takes the count and size as parameters, and then by default, it just calls the existing method. The checkVersion logic can then call the new method. Because we're not sure of the performance (and because we also don't want to do extra work), I propose that we make both lazy (i.e., a supplier of type CompletableFuture).
Hopefully, this could then be used by a user to solve #7.
The text was updated successfully, but these errors were encountered:
When the estimated size is exposed (see #1229), we should also allow users to use it in
checkVersion
instead of the record count. The size could, in theory, be more useful on record stores that don't have an appropriate index (or for whom executing a query against the index is too costly).I think there's a way to make this backwards compatible. At some point, we may want to make using the size the default. However, there are also some unknowns about the performance of this on large stores, so until we know that for sure, I think it should be opt-in.
To make this backwards compatible, I propose adding a new method to the
UserVersionChecker
that takes the count and size as parameters, and then by default, it just calls the existing method. ThecheckVersion
logic can then call the new method. Because we're not sure of the performance (and because we also don't want to do extra work), I propose that we make both lazy (i.e., a supplier of typeCompletableFuture
).Hopefully, this could then be used by a user to solve #7.
The text was updated successfully, but these errors were encountered: