JiriOndrusek opened a new pull request, #9006: URL: https://github.com/apache/camel-quarkus/pull/9006
fixes https://github.com/apache/camel-quarkus/issues/9003 _This work is not plugged into any existing code: no current extension or code path changes behaviour, the module is purely additive and exists as groundwork for an upcoming declarative ingestion feature (a future `langchain4j-ingest` extension's `sync` mode)._ Adds the bookkeeping layer for keeping a vector store in sync with a changing document source, tracked by #9003. - `IngestionTracker` SPI (`extensions-support/langchain4j`): one row per document — fingerprint, content hash, committed/intended segment counts, two-phase `in_progress`/`done`/`failed` status, `tombstone`/`pinned` flags. The module README documents the full document-state machine. - `JdbcIngestionTracker`: reference implementation with dialect-free SQL (PostgreSQL and H2), JDK types only, owning its `cq_ingestion_tracker` schema. - `JdbcIngestionTrackerTest`: the behavioural contract on H2 — its test methods are written against the SPI only and are meant to be extracted into a shared contract base class once a second implementation exists. - `integration-tests/langchain4j-ingestion-tracker`: the same guarantees over REST against a real PostgreSQL (Dev Services), with a native twin. Status: **experimental, internal SPI** — not consumed by any user-facing extension yet; it is the foundation for a future `langchain4j-ingest` extension's `sync` mode. LangChain4j has no equivalent of LangChain-Python's `RecordManager` (langchain4j/langchain4j#2931), so this fills the gap deliberately as a stopgap: if an upstream record manager lands, the SPI is designed to be replaced wholesale by an adapter over it — no long-term compatibility promise is made. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- Uncomment and fill this section if your PR is not trivial [ ] An issue should be filed for the change unless this is a trivial change (fixing a typo or similar). One issue should ideally be fixed by not more than one commit and the other way round, each commit should fix just one issue, without pulling in other changes. [ ] Each commit in the pull request should have a meaningful and properly spelled subject line and body. Copying the title of the associated issue is typically enough. Please include the issue number in the commit message prefixed by #. [ ] The pull request description should explain what the pull request does, how, and why. If the info is available in the associated issue or some other external document, a link is enough. [ ] Phrases like Fix #<issueNumber> or Fixes #<issueNumber> will auto-close the named issue upon merging the pull request. Using them is typically a good idea. [ ] Please run mvn process-resources -Pformat (and amend the changes if necessary) before sending the pull request. [ ] Contributor guide is your good friend: https://camel.apache.org/camel-quarkus/latest/contributor-guide.html --> -- 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]
