janhoy commented on code in PR #4853:
URL: https://github.com/apache/solr/pull/4853#discussion_r4034491600


##########
solr/modules/extraction/src/java/org/apache/solr/handler/extraction/ExtractingParams.java:
##########
@@ -157,4 +161,12 @@ public interface ExtractingParams {
 
   /** Default or per-request timeout in seconds for TikaServer HTTP calls. */
   String TIKASERVER_TIMEOUT_SECS = "tikaserver.timeoutSeconds";
+
+  /**
+   * If true, migrate metadata key names emitted by Tika 4.x back to their 
Tika 3.x equivalents
+   * (e.g. {@code tk:parsed-by} becomes {@code X-TIKA:Parsed-By}), using 
Tika's own bundled {@code
+   * LegacyKeyMigrationFilter} migration table. Keys with no Tika 3.x 
equivalent are dropped;
+   * migrated keys replace their Tika 4.x originals rather than being added 
alongside them.
+   */
+  String TIKASERVER_LEGACY_FIELD_NAMES = "tikaserver.legacyFieldNames";

Review Comment:
   Are you aware of line 148 in this file
   ```java
   /** Preferred: Fix/normalize metadata naming for Tika Server compatibility */
   String TIKASERVER_METADATA_COMPATIBILITY = 
"tikaserver.metadata.compatibility";
   ```
   
   It is the pre-existing flag that 10.0 users have been able to set for a 
best-effort back-fill of Tika3 metadata names to Tika1 compatible names (which 
was what users of 9.x will be used to).
   
   Maybe we could give them both, in a two staged approach, by renaming this 
new param of yours to more resemble the existing param:
   
   ```java
   String TIKASERVER_METADATA_COMPATIBILITY = 
"tikaserver.metadata.compatibility"; // implicit Tika3->1
   String TIKASERVER_METADATA_COMPATIBILITY_4 = 
"tikaserver.metadata.compatibility4"; // explicit Tika4->3
   ```
   
   Then users who only need the tika4 metadata and are happy, don't set any 
flag. But users who have code relying on Tika3 can set 
`-Dtikaserver.metadata.compatibility4=true`, while users relying on the Solr9.x 
Tika1 format, and may be running with the pre-existing flag already, may set 
both and if we execute the compatibility4 mappings first, then do the legacy 
one, users will get **a bunch of metadata fields** from here to the stone age 
and be happy as the Flintstones, yea?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to