-
Notifications
You must be signed in to change notification settings - Fork 37
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
Add cross-partition scan options #1294
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We no longer need this test class because it only tests if the scan is relational or not, and now we test it in OperationChecker
instead. Ditto for other storage.
} | ||
} else { | ||
return buildSelectQueryForScan(scan, tableMetadata); | ||
return buildSelectQuery((ScanAll) scan, tableMetadata); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After introducing the cross-partition scan concept, I was convinced that we don't have to distinguish ScanAll
and RelationalScan
anymore. This is a kind of refactoring, but I included this since it is related to re-organizing relational scan terminology.
@@ -90,6 +98,18 @@ protected void load() { | |||
activeTransactionManagementExpirationTimeMillis = | |||
getLong(getProperties(), ACTIVE_TRANSACTION_MANAGEMENT_EXPIRATION_TIME_MILLIS, -1); | |||
defaultNamespaceName = getString(getProperties(), DEFAULT_NAMESPACE_NAME, null); | |||
crossPartitionScanEnabled = getBoolean(getProperties(), CROSS_PARTITION_SCAN, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default value is false
in v4.0.0 or later, but it should be true
in v3.x for backward compatibility and warned when using it with SERIALIZABLE
. I will handle this after this PR is merged to the master.
|
||
private void warnCrossPartitionScan(String storageName) { | ||
logger.warn( | ||
"Enabling cross-partition scan for {} in production is not recommended " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[trivial] I imagined what the message would be like (e.g., "Enabling cross-partition scan for cosmos in production ..."), and I think adding quotations might be a bit better.
"Enabling cross-partition scan for {} in production is not recommended " | |
"Enabling cross-partition scan for '{}' in production is not recommended " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 7bffcbb. Thank you!
if (config.isCrossPartitionScanFilteringEnabled() | ||
|| config.isCrossPartitionScanOrderingEnabled()) { | ||
throw new IllegalArgumentException( | ||
"Cross-partition scan with filtering or ordering is not supported in Cassandra"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is related to https://github.com/scalar-labs/scalardb/pull/1294/files#diff-660ca76c9b64d94000e0854e2a18fdc5e6a69c028a74b8cacfa4ef733d4604c2L111, but sorry, I forgot why these types of scan were prohibitted. Could you tell me that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the question. Basically, it's hard to push down all kinds of filtering and ordering to NoSQL databases. But for filtering, we can support ScalarDB-side filtering in the near future since we already have a logic for evaluating all types of our predicates.
[skip ci]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a minor comment, but LGTM! Thank you!
@@ -81,12 +83,14 @@ public class JdbcConfig { | |||
public JdbcConfig(DatabaseConfig databaseConfig) { | |||
String storage = databaseConfig.getStorage(); | |||
String transactionManager = databaseConfig.getTransactionManager(); | |||
if (!"jdbc".equals(storage) && !"jdbc".equals(transactionManager)) { | |||
if (!storage.equals(STORAGE_NAME) && !transactionManager.equals(STORAGE_NAME)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, when we set the transactionManager
config to jdbc
, the storage
config is not required. So the storage
config can be null. So we need to use the STORAGE_NAME.equals(...)
style to avoid NullPointerExceptiom
:
if (!storage.equals(STORAGE_NAME) && !transactionManager.equals(STORAGE_NAME)) { | |
if (!STORAGE_NAME.equals(storage) && !STORAGE_NAME.equals(transactionManager)) { |
Or we also use Objects.equals()
as well. Either is fine for me. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brfrn169 Thank you for pointing it out. I think cassandra
is always set to the storage by default when we create DatabaseConfig
, it will never be null. If I understand it correctly, is the assertion better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, you are right. I don't remember why we used that reverse style ("jdbc".equals(storage)
) originally. It looks like we have default values for storage
and transactionManager
, so we don't need to care about NullPointerException
. So let's keep it as it is. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you!
(Sorry for my late review... 🙇♀️)
@Torch3333 I will merge this, but PTAL when you are back. |
Description
This PR introduces cross-partition scan options and the related errors and warnings so that developers can know
ScanAll
's behavior is different from the regularScan
and make sure to use it explicitly (at their own risk for NoSQL databases).Related issues and/or PRs
Changes made
DatabaseConfig
ScanAll
without filtering and orderingScanAll
with conjunctions (where clause)ScanAll
with orderingOperationChecker
)Checklist
Additional notes (optional)
RelationalScan
in tests, but keep them as is for nowRelease notes
Added cross-partition scan options