Skip to content

Conversation

@smiklosovic
Copy link
Contributor

Thanks for sending a pull request! Here are some tips if you're new here:

  • Ensure you have added or run the appropriate tests for your PR.
  • Be sure to keep the PR description updated to reflect all changes.
  • Write your PR title to summarize what this PR proposes.
  • If possible, provide a concise example to reproduce the issue for a faster review.
  • Read our contributor guidelines
  • If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

Comment on lines +209 to +210
"PRIMARY KEY ((keyspace_name, table_name), table_id, dict_id)) " +
"WITH CLUSTERING ORDER BY (table_id DESC, dict_id DESC)"; // in order to retrieve the latest dictionary; the contract is the newer the dictionary the larger the dict_id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should table_id be part of the partition key? (instead of being a clustering key).

dict_id is used to order the dictionaries for the same table. The table_id is not useful for the purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but that means that we would need to specify it every single time. If I just want to see what is there for keyspace / table I can't because I would need to know table id too. We also do not need to be afraid that we would fetch "too much" if PK is just keyspace and table, because these are retrieved in a lightweight manner anyway and we have a way how to clear orphaned too so ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair.

*/
@Nullable
public static List<LightweightCompressionDictionary> retrieveLightweightCompressionDictionaries(String keyspaceName, String tableName)
public static List<LightweightCompressionDictionary> retrieveLightweightCompressionDictionaries()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it only called by retrieveOrphanedLightweightCompressionDictionaries. If so, should they consolidate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is possible but I would just keep it how it is, I guess that having a way to just fetch everything, being it lightweight, does not hurt at all, for possible future usages we do not know how would look like yet.

@Command(name = "cleanup", description = "Clean up orphaned dictionaries by deleting them from " + SystemDistributedKeyspace.NAME
+ '.' + SystemDistributedKeyspace.COMPRESSION_DICTIONARIES +
" table, these are ones for which a table they were trained for was dropped.")
public static class CleanupDictionaries extends AbstractCommand
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about CleanupOrphanedDictionaries? Just to be super clear

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants