Skip to content

Add graph-level robust list handling GList. Add tests for G.#3893

Open
afs wants to merge 4 commits intoapache:mainfrom
afs:glist-g-tests
Open

Add graph-level robust list handling GList. Add tests for G.#3893
afs wants to merge 4 commits intoapache:mainfrom
afs:glist-g-tests

Conversation

@afs
Copy link
Copy Markdown
Member

@afs afs commented May 5, 2026

GList provides robust RDF list handling at the Graph level. It is neded to make writing SHALC 1.2 list validation.
Unlike GNode + GraphList, it is not working on generalized"findable" concept. It is executing with no unnecessary object creation.

It has checks for well-formed lists (one rdf:first, one rdf:rest per list cell, no cycles). It provides operations for accessing lists which check integrity but assume no cycles (cycle checking is moderately expensive for such low-level operations.

As part of this, creating tests has been an experiment in using the most basic, free co-pilot setup to generate tests. The task is not difficult and it is easy to check and review.

For GList, tests were first hand-written then copilot used to check coverage and add tests to be more comprehensive.

The class G has been around for a while. It is a low level internal API for wrapping up getting data out of graphs, such as checking one object is present for an SP lookup and always closing iterators, to reduce boilerplate in graph access code. The idea is to have a static import of the class so the functions become words available for writing code. DSL-ish.

G originally started small and testing was by usage. But its grown. It would benefit from its own tests. G should be easy because it is many small, self-contained functions, no class state, with javadoc. It should not be a not very demanding task, it is (human) time consuming.

The experiment is to use the default, free, co-pilot setup in Eclipse to see how it feels for individuals without enterprise-paid-for accounts.

And does it save time?

Learnings:

For increasing the coverage for GList, it has been sucessful.

My first attempt was building a single test file for G started OK. I was adding in groups of related operations to allow for review, e.g. all the SP accessors. But as more chunks were added, copilot "decided" to revise the earlier tests, lost track of coverage, lost earlier work and I could get it to backtrack and recover. It seems it lost the basic context. I threw the work away, got it to forget the last 24 hours (elapsed) and started again with one file per chunk.

That has been reasonably successful. Not a massive time saving but it was task that needed doing and wasn't happening. It still needs reviewing but the biggest advantage is that it is easier to spend my time in chunks on it across a few days with little (human) context-switching costs.

In one case, it found one bug. I fixed it manually. I didn't let copilot change any src/main code because ...
In another case, it confidently offered to change the implementation to match the test but the test was wrong.


  • Tests are included.

By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.

@afs afs added task Task AI Assisted Assisted or generated by AI labels May 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Assisted Assisted or generated by AI task Task

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant