Skip to content

Sort query results by exactly one, deliberately chosen property (#129) - #153

Draft
apdavison wants to merge 1 commit into
HumanBrainProject:masterfrom
apdavison:fix-sorting
Draft

apdavison wants to merge 1 commit into
HumanBrainProject:masterfrom
apdavison:fix-sorting

Conversation

@apdavison

@apdavison apdavison commented Sep 30, 2026 •

Copy link
Copy Markdown
Member

Fixes #129

This PR is part of an experiment comparing the performance of different AI coding agents. The other PR addressing the same issue is #154.

This implementation made use of Claude Opus 5.5 running in Claude Code. The initial prompt, in a checkout of my fork of fairgraph, was "Please make a plan to address issue #129 from the upstream HumanBrainProject/fairgraph repository".

One notable feature of the planning process was that Claude asked what priority should be given to different properties when deciding which to sort on ("name", "lookupLabel", etc.), and one if its suggestions was a per-class priority. This was the suggestion I went with, although I suggested a different implementation to the one Claude proposed.

The KG query API allows "sort": true on only one root-level property, but generate_query() flagged every property named name, fullName or lookupLabel, so classes with both name and lookup_label sent two sort keys and the KG used whichever came first. Each generated class now has a sort_property attribute, chosen by the builder from a priority order (name, full_name, lookup_label, family_name) with per-class exceptions: ParcellationEntity and ParcellationEntityVersion sort by lookup_label, which keeps entities from the same atlas together. Query.serialize() now rejects queries with more than one sort key.

As a result, SlicingDevice, Electrode, ElectrodeArray and Pipette are sorted by name instead of lookup_label, and Person is now sorted by family_name.

Adds offline tests over all v4 and v5 classes, live tests of the KG's ordering (case-insensitive, missing values first), and documentation of result ordering, including that the core API, used by default for unfiltered list(), does not sort.

Implementation made use of Claude Opus 5.5
@apdavison apdavison added this to the 0.16 milestone Sep 30, 2026
@apdavison apdavison added the bug Something isn't working label Sep 30, 2026
@apdavison
apdavison marked this pull request as draft September 30, 2026 09:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ensure consistent and robust sorting

1 participant