[
https://issues.apache.org/jira/browse/CALCITE-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18023706#comment-18023706
]
Julian Hyde commented on CALCITE-7205:
--------------------------------------
First, the testing strategy. I don't think the usual "unit test" strategy works
well here. Unit tests and integration tests work well when you have a
well-defined low level component, for which you write unit tests, and you want
to make sure that it composes well with other components, for which you write
integration tests. Here, what is well-defined is what we want to appear through
the metadata API, the "middle level". Whatever we create at a lower level is in
service of that. There are a lot of existing tests at that middle level, namely
RelMetadataTest. That pattern works, and I don't see a reason to depart from it.
Second, regarding the naming and decomposition of the lower-level classes. The
core idea of functional dependency is a verb, for example "empno functionally
determines deptno". But we need a class to hold data, and experience has shown
that such classes are best named after countable, concrete nouns with short
names, like "map" and "list".
"Functional dependency" *is* a noun, but it is abstract (like "liberty"), and
is difficult to define it so that it is countable: if empno functionally
determines both deptno and sal, is that one functional dependency or two? I
suggested "Arrow" because to it can represent a mapping element "empno →
deptno" and gives us freedom to alter the low-level model - maybe introducing
variants like "(job, deptno) → sal" and "empno → (hiredate, job)" -
without having to change the mid-level API and all the tests.
I'm sorry to have a strident opinion, but naming is important because it lets
us think about, document, and refactor the code.
Your proposed name "IndicesDependencyItem" seems to fulfill the criteria of
being countable and concrete. But it's not short (otherwise you probably would
be suggesting "IndicesDependencyItems" as a utility class), and it's not
self-evident what the "indices" pertain to.
> Implement Core FD Algorithm Library for Functional Dependencies
> ---------------------------------------------------------------
>
> Key: CALCITE-7205
> URL: https://issues.apache.org/jira/browse/CALCITE-7205
> Project: Calcite
> Issue Type: Task
> Components: core
> Affects Versions: 1.40.0
> Reporter: Zhen Chen
> Assignee: Zhen Chen
> Priority: Minor
> Labels: pull-request-available
>
> This JIRA primarily provides foundational capabilities for *relational
> algebra and metadata reasoning*.
> *Main Implementations:*
> * Encapsulates functional dependency (FD) sets, supporting basic operations
> such as addition, deletion, and query.
> * Provides algorithms for closure computation, equivalence judgment, and
> candidate key discovery.
> * Supports efficient attribute reasoning and dependency reasoning,
> facilitating use by upper-layer optimizers and metadata modules.
> Please refer to the discussion in the PR for [more
> details|https://github.com/apache/calcite/pull/4540#discussion_r2384265382].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
