From 543c24d084c82da597f4732d73c5dade862539bb Mon Sep 17 00:00:00 2001
From: Cam Saul <cammsaul@gmail.com>
Date: Wed, 9 Aug 2017 14:41:01 -0700
Subject: [PATCH] Remove fingerprint versioning stuff from sync scheduling PR
---
src/metabase/sync/interface.clj | 33 ---------------------------------
1 file changed, 33 deletions(-)
diff --git a/src/metabase/sync/interface.clj b/src/metabase/sync/interface.clj
index 9ef49ee06f8..7087972b797 100644
--- a/src/metabase/sync/interface.clj
+++ b/src/metabase/sync/interface.clj
@@ -101,36 +101,3 @@
(s/optional-key :global) GlobalFingerprint
(s/optional-key :type) TypeSpecificFingerprint
(s/optional-key :experimental) {s/Keyword s/Any}})
-
-
-;;; +------------------------------------------------------------------------------------------------------------------------+
-;;; | FINGERPRINT VERSIONING |
-;;; +------------------------------------------------------------------------------------------------------------------------+
-
-;; Occasionally we want to update the schema of our Field fingerprints and add new logic to populate the additional keys.
-;; However, by default, analysis (which includes fingerprinting) only runs on *NEW* Fields, meaning *EXISTING* Fields won't
-;; get new fingerprints with the updated info.
-;;
-;; To work around this, we can use a versioning system. Fields whose Fingerprint's version is lower than the current version
-;; should get updated during the next sync/analysis regardless of whether they are or are not new Fields. However, this could
-;; be quite inefficient: if we add a new fingerprint field for `:type/Number` Fields, why should we re-fingerprint `:type/Text`
-;; Fields? Ideally, we'd only re-fingerprint the numeric Fields.
-;;
-;; Thus, our implementation below. Each new fingerprint version lists a set of types that should be upgraded to it. Our
-;; fingerprinting logic will calculate whether a fingerprint needs to be recalculated based on its version and the changes
-;; that have been made in subsequent versions. Only the Fields that would benefit from the new Fingerprint info need be
-;; re-fingerprinted.
-;;
-;; Thus, if Fingerprint v2 contains some new info for numeric Fields, only Fields that derive from `:type/Number` need be upgraded
-;; to v2. Textual Fields with a v1 fingerprint can stay at v1 for the time being. Later, if we introduce a v3 that includes new
-;; "global" fingerprint info, both the v2-fingerprinted numeric Fields and the v1-fingerprinted textual Fields can be upgraded
-;; to v3.
-
-(def ^:const ^Integer current-fingerprint-version
- "The current version of our Field fingerprint. See comments above for explanation of how this is used."
- 2)
-
-(def fingerprint-version->types-that-should-be-re-fingerprinted
- "Map of fingerprint version to the set of Field base types that need to be upgraded to this version the next
- time we do analysis."
- {2 #{:type/Number}})
--
GitLab