v2.5.0 — Property-side read primitives

What's New

Nine property-side read primitives for IRISGraphEngine. Same pattern as get_node_ids_by_label, applied to rdf_props. All use single-table SQL with TOP n — no JOIN, no FETCH FIRST.

New Methods

Method	Description
get_node_ids_by_property(key, val=None, limit=None)	Subject ids carrying a property key, optionally filtered to exact value
get_nodes_by_property(key, val=None, limit=None)	Hydrated node dicts for matching subjects
get_property_pairs(key)	(subject, value) pairs for all subjects under a key
get_property_values(key)	All values stored under a key (value-only scan)
property_value_exists(key, like)	TOP 1 LIKE probe — bool existence check
get_property_pairs_like(key, like, limit=None)	(subject, value) pairs with LIKE filter
get_json_field_values(key, field)	Server-side JSON field extraction via $PIECE
get_node_ids_like(pattern)	Node ids matching a SQL LIKE pattern
count_subjects_with_property(key, val=None)	COUNT of subjects carrying a property

Bug Fixes

• B3: kg_NEIGHBORS works correctly on all clean IRIS instances. The %qaqpre JOIN fault on one instance was a stale IRISLIB from a botched upgrade, not an ivg bug. kg_NEIGHBORS stays Cypher-based.
• B4: kg_KNN_VEC already logs WARNING "Server-side kg_KNN_VEC failed … Falling back to client-side logic" on Python fallback. No change needed.

Notes

• All nine methods return [], False, or 0 on DB exception.
• Non-positive limit emits no TOP clause (avoids TOP 0 footgun).
• replace_multivalued_property is not included — rdf_props has PRIMARY KEY (s, key), so multi-valued properties are structurally impossible.

Testing

47 tests: 32 unit (mocked, no container) + 15 integration (ivg-iris Community container).