refactor(indexing): forward CSV and XML to Solr's own update handlers

[adityamparikh]

Summary

Solr already parses CSV and its own update XML. The server's CSV and XML document creators re-implemented that, and the XML one did it with a convention of its own: a generic <shows><show> mapping that prefixed every field with the record element (show_title) and dropped the id, so XML was the one format whose documents did not match the same data in JSON, CSV or Markdown.

Both creators are removed. The two tools now forward the payload, as given, to Solr's own update handlers:

• index-csv-documents sends the CSV to Solr's CSV handler with header=true. Solr reads the header for the field names, so column names are used as given (no lower-casing or underscoring). Repeated column names are multi-valued fields and empty cells are skipped. The server does not parse the payload at all; commons-csv is dropped.
• index-xml-documents takes Solr's update XML, <add><doc><field name="id">…</field><field name="genres">a</field><field name="genres">b</field></doc></add>, the format every Solr user already has, and sends it as-is.

The <add> guard

Solr's update XML grammar is a command language: <delete>, <commit>, <optimize> and <rollback> go to the same endpoint as <add> (Ref Guide: Indexing with Update Handlers). A tool that forwarded blindly would let an indexing call delete a collection. SolrJ only writes update XML and Solr's own XMLLoader lives in solr-core, so the check has to be local: SolrUpdateXml.requireAddBlock reads the payload with a hardened StAX parser (DTD off, external entities off) only as far as the root element, rejects a DOCTYPE outright, and rejects any root but <add>. Nothing past the root is inspected; Solr parses the body and accepts or rejects it as a whole.

The parser is Spring's StaxUtils.createDefensiveInputFactory(), which sets those two properties and additionally installs a no-op XMLResolver. It is held in a static field, since XMLInputFactory.newFactory() runs a ServiceLoader scan of the whole classpath on every call and the factory is never reconfigured after construction.

What the tools report

Solr's update response carries a status and a QTime but no document count, so the two tools no longer claim "indexed N of N". They report that Solr accepted and committed the payload, with status and QTime, and the index-data prompt points at check-health / *:* for the count.

The commit rides on the update request itself (setAction(ACTION.COMMIT)) rather than following as a second POST, so the status and QTime reported cover the commit the message claims.

What this removes

XmlDocumentCreator, CsvDocumentCreator, their two Spring test classes, the orchestrator's CSV/XML paths and the commons-csv dependency: about 500 lines of parsing and mapping. What remains is SolrUpdateXml (about 30 lines) with a plain unit test, unit tests on the service, and real-Solr integration tests that index CSV and XML through the tools and query the documents back, including the rejected <delete>.

ShowsSampleDataIntegrationTest indexes the same 61 shows through all three tools into three collections and asserts the retrieved documents are field-for-field identical, so a tutorial step written against one format holds for the others.

Native image

The sample-data fixtures are registered for the native test binary through a TestRuntimeHintsRegistrar wired via src/test/resources/META-INF/spring/aot.factories, rather than a -H:IncludeResources option in the Gradle args list — the seam dev-docs/graalvm-native-image.md prescribes. It lives in test sources because SolrNativeHints is the production equivalent and must not ship test fixture names in the application image.

The patterns name the three fixtures rather than matching by extension: registerPattern compiles * to .*, which crosses /, so a *.xml there would embed all 124 XML resources on this project's 210-jar test classpath. Spring AOT registers .*\.json globally, so shows.json was already covered while its CSV and XML siblings were not; registering all three keeps the dataset covered in one place.

Behaviour changes

• CSV column names and XML <field name> values are used as given; neither is sanitized any more (JSON and Markdown still are).
• Generic element-per-field XML is no longer accepted (it was never a Solr format).
• Solr accepts or rejects a CSV or XML payload as a whole; the per-document retry that produced "60 of 61" applies to JSON and Markdown only, and CSV/XML responses no longer state a count.
• A CSV or XML index is one request to Solr instead of two.

🤖 Generated with Claude Code

https://claude.ai/code/session_014XuwC2kdJ6Q1dDDZMHDCee