LMDB Store: working on new ID based join iterator

AGENTS.md

@@ -4,8 +4,6 @@ Welcome, AI Agent! Your persistence, curiosity, and craftsmanship make a differe
 
 You need to read the entire AGENTS.md file and follow all instructions exactly. Keep this fresh in your context as you work.
 
-> **Timebox:** Aim to complete each autonomous run in **15–30 minutes**.
-
 ---
 
 ## Read‑Me‑Now: Proportional Test‑First Rule (Default)
@@ -27,59 +25,52 @@ It is illegal to `-am` when running tests!
 It is illegal to `-q` when running tests!
 
 > **Clarification:** For **strictly behavior‑neutral refactors** that are already **fully exercised by existing tests**, or for **bugfixes with an existing failing test**, you may use **Routine B — Change without new tests**. In that case you must capture **pre‑change passing evidence** at the smallest scope that hits the code you’re about to edit, prove **Hit Proof**, then show **post‑change passing evidence** from the **same selection**.
-> **No exceptions for any behavior‑changing change** — for those, you must follow **Routine A — Full TDD**.
+> **No exceptions for any behavior‑changing change** — for those, you must follow **Routine A — Full TDD** or **Routine D — ExecPlans**.
 
 ---
 
-## Three Routines: Choose Your Path
+## Four Routines: Choose Your Path
 
 **Routine A — Full TDD (Default)**
 **Routine B — Change without new tests (Proportional, gated)**
 **Routine C — Spike/Investigate (No production changes)**
+**Routine D — ExecPlans: Complex features or significant refactors**
 
 ### Decision quickstart
 
-1. **Is new externally observable behavior required?**
+1. **Is ExecPlans required (complex feature, significant refactor or requested by the user)?**
+   → **Yes:** **Routine D (ExecPlans)**. Use an ExecPlan (as described in .agent/PLANS.md) from design to implementation.
+   → **No:** continue.
+
+2**Is new externally observable behavior required?**
    → **Yes:** **Routine A (Full TDD)**. Add the smallest failing test first.
    → **No:** continue.
 
-2. **Does a failing test already exist in this repo that pinpoints the issue?**
+3**Does a failing test already exist in this repo that pinpoints the issue?**
    → **Yes:** **Routine B (Bugfix using existing failing test).**
    → **No:** continue.
 
-3. **Is the edit strictly behavior‑neutral, local in scope, and clearly hit by existing tests?**
+4**Is the edit strictly behavior‑neutral, local in scope, and clearly hit by existing tests?**
    → **Yes:** **Routine B (Refactor/micro‑perf/documentation/build).**
    → **No or unsure:** continue.
 
-4. **Is this purely an investigation/design spike with no production code changes?**
+5**Is this purely an investigation/design spike with no production code changes?**
    → **Yes:** **Routine C (Spike/Investigate).**
    → **No or unsure:** **Routine A.**
 
 **When in doubt, choose Routine A (Full TDD).** Ambiguity is risk; tests are insurance.
 
 ---
 
-## PIOSEE Decision Model (Adopted)
+## ExecPlans
 
-Use PIOSEE on every task to structure thinking and execution. It complements the routines below and ties directly into the Traceability trio (Description, Evidence, Plan).
+When writing complex features or significant refactors, use an ExecPlan (as described in PLANS.md) from design to implementation.
 
-- Problem: restate the task in one sentence, note constraints/timebox, and identify likely routine (A/B/C).
-- Information: inspect modules and AGENTS.md, gather environment constraints, locate existing tests/reports, and search code to localize the work.
-- Options: list 2–3 viable approaches (routine choice, test scope, fix location) and weigh them with the Proportionality Model.
-- Select: choose one option and routine; update the Living Plan with exactly one `in_progress` step.
-- Execute: follow the Working Loop and house rules; for Routine A add the smallest failing test first; capture an Evidence block after each grouped action.
-- Evaluate: check against the Definition of Done; if gaps remain, adjust the plan or change routine; record final Evidence and a brief retrospective.
-
-PIOSEE → Traceability trio mapping
-- P/I/O → Description
-- S → Plan (one `in_progress`)
-- E/E → Evidence and Verification
-
-For documentation‑only edits and other Routine B cases, still run PIOSEE briefly to confirm neutrality and reversibility.
+---
 
 ## Proportionality Model (Think before you test)
 
-Score the change on these lenses. If any are **High**, prefer **Routine A**.
+Score the change on these lenses. If any are **High**, prefer **Routine A or D**.
 
 - **Behavioral surface:** affects outputs, serialization, parsing, APIs, error text, timing/order?
 - **Blast radius:** number of modules/classes touched; public vs internal.
@@ -101,7 +92,7 @@ Score the change on these lenses. If any are **High**, prefer **Routine A**.
     * Relevant module tests pass; failures triaged or crisply explained.
     * Only necessary files changed; headers correct for new files.
     * Clear final summary: what changed, why, where, how verified, next steps.
-    * **Evidence present:** failing test output (pre‑fix) and passing output (post‑fix) are shown for Routine A; for Routine B show **pre/post green** from the **same selection** plus **Hit Proof**.
+    * **Evidence present:** failing test output (pre‑fix) and passing output (post‑fix) are shown for Routine A; for Routine B show **pre/post green** from the **same selection** plus **Hit Proof**; for Routine D NO EVIDENCE.
 
 ### No Monkey‑Patching or Band‑Aid Fixes (Non‑Negotiable)
 
@@ -336,6 +327,14 @@ It is illegal to `-q` when running tests!
 
 ---
 
+## Routine D — ExecPlans
+
+> Use for **complex features or significant refactors**.
+
+When writing complex features or significant refactors, use an ExecPlan (as described in .agent/PLANS.md) from design to implementation.
+
+---
+
 ## Where to Draw the Line — A Short Debate
 
 > **Purist:** “All changes must start with a failing test.”
@@ -349,7 +348,7 @@ It is illegal to `-q` when running tests!
 * Logging/message tweaks **not** asserted by tests.
 * Build/CI config that doesn’t alter runtime behavior.
 
-**Out‑of‑scope (use Routine A)**
+**Out‑of‑scope (use Routine A/D)**
 * Changing query results, serialization, or parsing behavior.
 * Altering error messages that tests assert.
 * Anything touching concurrency, timeouts, IO, or ordering.
@@ -360,8 +359,7 @@ It is illegal to `-q` when running tests!
 
 ## Working Loop
 
-* **PIOSEE first:** restate Problem, gather Information, list Options; then Select, Execute, Evaluate.
-* **Plan:** small, verifiable steps; keep one `in_progress`.
+* **Plan:** small, verifiable steps; keep one `in_progress`, or follow PLANS.md (ExecPlans)
 * **Change:** minimal, surgical edits; keep style/structure consistent.
 * **Format:** `mvn -o -Dmaven.repo.local=.m2_repo -q -T 2C formatter:format impsort:sort xml-format:xml-format`
 * **Compile (fast):** `mvn -o -Dmaven.repo.local=.m2_repo -pl <module> -am -Pquick install | tail -500`
@@ -525,11 +523,11 @@ Do **not** modify existing headers’ years.
 * **Files touched:** list file paths.
 * **Commands run:** key build/test commands.
 * **Verification:** which tests passed, where you checked reports.
-* **PIOSEE trace (concise):** P/I/O summary, selected option/routine, key evaluate outcomes.
 * **Evidence:**
   *Routine A:* failing output (pre‑fix) and passing output (post‑fix).
   *Routine B:* pre‑ and post‑green snippets from the **same selection** + **Hit Proof**.
   *Routine C:* artifacts from investigation (logs/notes/measurements) and proposed next steps.
+  *Routine D:* NO EVIDENCE REQUIRED.
 * **Assumptions:** key assumptions and autonomous decisions.
 * **Limitations:** anything left or risky edge cases.
 * **Next steps:** optional follow‑ups.

PLANS.md

@@ -1,77 +1,77 @@
 # Codex Execution Plans (ExecPlans):
- 
+
 This document describes the requirements for an execution plan ("ExecPlan"), a design document that a coding agent can follow to deliver a working feature or system change. Treat the reader as a complete beginner to this repository: they have only the current working tree and the single ExecPlan file you provide. There is no memory of prior plans and no external context.
- 
+
 ## How to use ExecPlans and PLANS.md
- 
+
 When authoring an executable specification (ExecPlan), follow PLANS.md _to the letter_. If it is not in your context, refresh your memory by reading the entire PLANS.md file. Be thorough in reading (and re-reading) source material to produce an accurate specification. When creating a spec, start from the skeleton and flesh it out as you do your research.
- 
+
 When implementing an executable specification (ExecPlan), do not prompt the user for "next steps"; simply proceed to the next milestone. Keep all sections up to date, add or split entries in the list at every stopping point to affirmatively state the progress made and next steps. Resolve ambiguities autonomously, and commit frequently.
- 
+
 When discussing an executable specification (ExecPlan), record decisions in a log in the spec for posterity; it should be unambiguously clear why any change to the specification was made. ExecPlans are living documents, and it should always be possible to restart from _only_ the ExecPlan and no other work.
- 
+
 When researching a design with challenging requirements or significant unknowns, use milestones to implement proof of concepts, "toy implementations", etc., that allow validating whether the user's proposal is feasible. Read the source code of libraries by finding or acquiring them, research deeply, and include prototypes to guide a fuller implementation.
- 
+
 ## Requirements
- 
+
 NON-NEGOTIABLE REQUIREMENTS:
- 
+
 * Every ExecPlan must be fully self-contained. Self-contained means that in its current form it contains all knowledge and instructions needed for a novice to succeed.
 * Every ExecPlan is a living document. Contributors are required to revise it as progress is made, as discoveries occur, and as design decisions are finalized. Each revision must remain fully self-contained.
 * Every ExecPlan must enable a complete novice to implement the feature end-to-end without prior knowledge of this repo.
 * Every ExecPlan must produce a demonstrably working behavior, not merely code changes to "meet a definition".
 * Every ExecPlan must define every term of art in plain language or do not use it.
- 
+
 Purpose and intent come first. Begin by explaining, in a few sentences, why the work matters from a user's perspective: what someone can do after this change that they could not do before, and how to see it working. Then guide the reader through the exact steps to achieve that outcome, including what to edit, what to run, and what they should observe.
- 
+
 The agent executing your plan can list files, read files, search, run the project, and run tests. It does not know any prior context and cannot infer what you meant from earlier milestones. Repeat any assumption you rely on. Do not point to external blogs or docs; if knowledge is required, embed it in the plan itself in your own words. If an ExecPlan builds upon a prior ExecPlan and that file is checked in, incorporate it by reference. If it is not, you must include all relevant context from that plan.
- 
+
 ## Formatting
- 
+
 Format and envelope are simple and strict. Each ExecPlan must be one single fenced code block labeled as `md` that begins and ends with triple backticks. Do not nest additional triple-backtick code fences inside; when you need to show commands, transcripts, diffs, or code, present them as indented blocks within that single fence. Use indentation for clarity rather than code fences inside an ExecPlan to avoid prematurely closing the ExecPlan's code fence. Use two newlines after every heading, use # and ## and so on, and correct syntax for ordered and unordered lists.
- 
+
 When writing an ExecPlan to a Markdown (.md) file where the content of the file *is only* the single ExecPlan, you should omit the triple backticks.
- 
+
 Write in plain prose. Prefer sentences over lists. Avoid checklists, tables, and long enumerations unless brevity would obscure meaning. Checklists are permitted only in the `Progress` section, where they are mandatory. Narrative sections must remain prose-first.
- 
+
 ## Guidelines
- 
+
 Self-containment and plain language are paramount. If you introduce a phrase that is not ordinary English ("daemon", "middleware", "RPC gateway", "filter graph"), define it immediately and remind the reader how it manifests in this repository (for example, by naming the files or commands where it appears). Do not say "as defined previously" or "according to the architecture doc." Include the needed explanation here, even if you repeat yourself.
- 
+
 Avoid common failure modes. Do not rely on undefined jargon. Do not describe "the letter of a feature" so narrowly that the resulting code compiles but does nothing meaningful. Do not outsource key decisions to the reader. When ambiguity exists, resolve it in the plan itself and explain why you chose that path. Err on the side of over-explaining user-visible effects and under-specifying incidental implementation details.
- 
+
 Anchor the plan with observable outcomes. State what the user can do after implementation, the commands to run, and the outputs they should see. Acceptance should be phrased as behavior a human can verify ("after starting the server, navigating to [http://localhost:8080/health](http://localhost:8080/health) returns HTTP 200 with body OK") rather than internal attributes ("added a HealthCheck struct"). If a change is internal, explain how its impact can still be demonstrated (for example, by running tests that fail before and pass after, and by showing a scenario that uses the new behavior).
- 
+
 Specify repository context explicitly. Name files with full repository-relative paths, name functions and modules precisely, and describe where new files should be created. If touching multiple areas, include a short orientation paragraph that explains how those parts fit together so a novice can navigate confidently. When running commands, show the working directory and exact command line. When outcomes depend on environment, state the assumptions and provide alternatives when reasonable.
- 
+
 Be idempotent and safe. Write the steps so they can be run multiple times without causing damage or drift. If a step can fail halfway, include how to retry or adapt. If a migration or destructive operation is necessary, spell out backups or safe fallbacks. Prefer additive, testable changes that can be validated as you go.
- 
+
 Validation is not optional. Include instructions to run tests, to start the system if applicable, and to observe it doing something useful. Describe comprehensive testing for any new features or capabilities. Include expected outputs and error messages so a novice can tell success from failure. Where possible, show how to prove that the change is effective beyond compilation (for example, through a small end-to-end scenario, a CLI invocation, or an HTTP request/response transcript). State the exact test commands appropriate to the project’s toolchain and how to interpret their results.
- 
+
 Capture evidence. When your steps produce terminal output, short diffs, or logs, include them inside the single fenced block as indented examples. Keep them concise and focused on what proves success. If you need to include a patch, prefer file-scoped diffs or small excerpts that a reader can recreate by following your instructions rather than pasting large blobs.
- 
+
 ## Milestones
- 
+
 Milestones are narrative, not bureaucracy. If you break the work into milestones, introduce each with a brief paragraph that describes the scope, what will exist at the end of the milestone that did not exist before, the commands to run, and the acceptance you expect to observe. Keep it readable as a story: goal, work, result, proof. Progress and milestones are distinct: milestones tell the story, progress tracks granular work. Both must exist. Never abbreviate a milestone merely for the sake of brevity, do not leave out details that could be crucial to a future implementation.
- 
+
 Each milestone must be independently verifiable and incrementally implement the overall goal of the execution plan.
- 
+
 ## Living plans and design decisions
- 
+
 * ExecPlans are living documents. As you make key design decisions, update the plan to record both the decision and the thinking behind it. Record all decisions in the `Decision Log` section.
 * ExecPlans must contain and maintain a `Progress` section, a `Surprises & Discoveries` section, a `Decision Log`, and an `Outcomes & Retrospective` section. These are not optional.
 * When you discover optimizer behavior, performance tradeoffs, unexpected bugs, or inverse/unapply semantics that shaped your approach, capture those observations in the `Surprises & Discoveries` section with short evidence snippets (test output is ideal).
 * If you change course mid-implementation, document why in the `Decision Log` and reflect the implications in `Progress`. Plans are guides for the next contributor as much as checklists for you.
 * At completion of a major task or the full plan, write an `Outcomes & Retrospective` entry summarizing what was achieved, what remains, and lessons learned.
- 
+
 # Prototyping milestones and parallel implementations
- 
+
 It is acceptable—-and often encouraged—-to include explicit prototyping milestones when they de-risk a larger change. Examples: adding a low-level operator to a dependency to validate feasibility, or exploring two composition orders while measuring optimizer effects. Keep prototypes additive and testable. Clearly label the scope as “prototyping”; describe how to run and observe results; and state the criteria for promoting or discarding the prototype.
- 
+
 Prefer additive code changes followed by subtractions that keep tests passing. Parallel implementations (e.g., keeping an adapter alongside an older path during migration) are fine when they reduce risk or enable tests to continue passing during a large migration. Describe how to validate both paths and how to retire one safely with tests. When working with multiple new libraries or feature areas, consider creating spikes that evaluate the feasibility of these features _independently_ of one another, proving that the external library performs as expected and implements the features we need in isolation.
- 
+
 ## Skeleton of a Good ExecPlan
- 
+
 ```md
 # <Short, action-oriented description>
 
@@ -146,7 +146,7 @@ In crates/foo/planner.rs, define:
         fn plan(&self, observed: &Observed) -> Vec<Action>;
     }
 ```
- 
+
 If you follow the guidance above, a single, stateless agent -- or a human novice -- can read your ExecPlan from top to bottom and produce a working, observable result. That is the bar: SELF-CONTAINED, SELF-SUFFICIENT, NOVICE-GUIDING, OUTCOME-FOCUSED.
- 
+
 When you revise a plan, you must ensure your changes are comprehensively reflected across all sections, including the living document sections, and you must write a note at the bottom of the plan describing the change and the reason why. ExecPlans must describe not just the what but the why for almost everything.

core/common/iterator/src/main/java/org/eclipse/rdf4j/common/iteration/Iterations.java

@@ -43,6 +43,17 @@ public static <E> List<E> asList(CloseableIteration<? extends E> iteration) {
 		}
 	}
 
+	public static long count(CloseableIteration<?> iteration) {
+		try (iteration) {
+			long count = 0;
+			while (iteration.hasNext()) {
+				iteration.next();
+				count++;
+			}
+			return count;
+		}
+	}
+
 	/**
 	 * Get a Set containing all elements obtained from the specified iteration.
 	 *

core/model-api/src/main/java/org/eclipse/rdf4j/model/base/AbstractIRI.java

@@ -124,20 +124,20 @@ private int split() {
 			}
 		}
 
-		@Override
-		public int hashCode() {
-			return iri.hashCode();
-		}
-
 		@Override
 		public boolean equals(Object o) {
-			if (o == this) {
+			if (this == o) {
 				return true;
 			}
-			if (!(o instanceof IRI)) {
-				return false;
+			if (o instanceof GenericIRI) {
+				// Fast-path for same concrete type: compare internal string directly
+				return this.iri.equals(((GenericIRI) o).iri);
+			}
+			if (o instanceof IRI) {
+				// Cross-type equality by lexical form
+				return stringValue().equals(((IRI) o).stringValue());
 			}
-			return iri.equals(o.toString());
+			return false;
 		}
 
 	}