Skip to content

Catalog clustering keys fixes#16351

Merged
zachjsh merged 7 commits intoapache:masterfrom
zachjsh:catalog-clustering-keys-fixes
May 3, 2024
Merged

Catalog clustering keys fixes#16351
zachjsh merged 7 commits intoapache:masterfrom
zachjsh:catalog-clustering-keys-fixes

Conversation

@zachjsh
Copy link
Contributor

@zachjsh zachjsh commented Apr 29, 2024

Description

This pr contains a few fixes for clustering keys when stored in the Druid table catalog.

  1. DESC order clustering keys is disallowed; descending clustering keys is not supported at this time by Druid, but previously users could create / update a catalog table with clustering keys with DESC order via api. This is now disallowed.
  2. Fixed a bug where when partitionedBy is defined for a table in the catalog, the user would still have to specify this partitioning if they also wished to define the clustering keys at query time. The error in such a case was coming from the SQL parsing layer. I've updated the respective ftl files to allow for this, and this validation has now moved to the DruidSqlValidator. In such a case the user should be able to omit the partitioning at query time, and still specify the clustering at query time.
  3. Added more tests.

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • a release note entry in the PR description.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added or updated version, license, or notice information in licenses.yaml
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

Copy link
Member

@kgyrtkirk kgyrtkirk left a comment

Choose a reason for hiding this comment

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

+1
left some notes; can be addressed in next pr as well


public class EditorTest
{
private static final ObjectMapper MAPPER = new DefaultObjectMapper();
Copy link
Member

Choose a reason for hiding this comment

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

note: dbFixture also has an OM you could probably reuse that somehow; I've seen some issue arising from using different objectmappers...

doEdit(tableName, cmd).spec().properties()
);

// Add a DESC cluster key - should fail
Copy link
Member

Choose a reason for hiding this comment

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

could be placed in a new testscase

expectValidationFails(spec);
}

{
Copy link
Member

Choose a reason for hiding this comment

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

aren't these 2 separate testcases?

@zachjsh zachjsh merged commit fb7c84f into apache:master May 3, 2024
@zachjsh zachjsh deleted the catalog-clustering-keys-fixes branch May 3, 2024 18:02
IgorBerman pushed a commit to IgorBerman/druid that referenced this pull request May 5, 2024
* * add another catalog clustering columns unit test

* * dissallow clusterKeys with descending order

* * make more clear that clustering is re-written into ingest node
whether a catalog table or not

* * when partitionedBy is stored in catalog, user shouldnt need to specify
it in order to specify clustering

* * fix intellij inspection failure
@kfaraz kfaraz added this to the 31.0.0 milestone Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants