How to test library(persistency) properly

Help!
1

From a Git Bash shell in VS Code (note that the Unix-style $ prompt and the Windows version output are both correct):

$ swipl --version
SWI-Prolog version 9.3.36 for x64-win64

I first attempted to locate test cases for library(persistency) in the official SWI-Prolog GitHub repository, but was unable to find any. If such tests exist elsewhere, I would very much like to study them.

While creating multiple test cases that rely on a knowledge base built using library(persistency)—for example:

:- begin_tests(core_predicates,
               [ setup(setup_isolated_kb),
                 cleanup(cleanup_isolated_kb)
               ]).

I have run into issues with sequential tests. Loading the persistent KB in one test can interfere with loading it in the next.

This made me wonder whether the KB-closing mechanism is contributing to the problem. Specifically, close_dbs/0 is not exported; it is only invoked via at_halt/1. Here is the relevant portion of the module:

:- module(persistency,
          [ (persistent)/1,                  % +Declarations
            current_persistent_predicate/1,  % :PI
            db_attach/2,                     % :File, +Options
            db_detach/0,
            db_attached/1,                   % :File
            db_sync/1,                       % :What
            db_sync_all/1,                   % +What
            op(1150, fx, (persistent))
          ]).

close_dbs :-
    forall(retract(db_stream(_Module, Stream)),
           close(Stream)).

:- at_halt(close_dbs).

In previous projects, library(persistency) worked reliably for proofs of concept, so I never created dedicated tests. For this new project, however, proper test coverage is essential. The lack of existing test cases, combined with insights from Claude Code and human review suggests that I may be encountering edge cases that require guidance to resolve, or that library(persistency) itself may need some adjustments to better support test-driven workflows.

My goal is not to fix my specific code but to understand at a higher level what is the correct approach for testing when using library(persistency).

2

I don’t think there are any test cases. At least, not in the official test suite. The library is designed to attach a KB once and leave it attached until program shutdown. It you want to test multiple scenarios you either have to fire a Prolog process per test or add code to close the KB. Note that closing does

1 Like
4

Thanks

Here is how I approached using that idea.

Searched the GitHub SWI-Prolog account for process_create (search)

Found swipl-devel/tests/test.pl at ff5d52cf236c5468f344f3e4ad163de787805de8 · SWI-Prolog/swipl-devel · GitHub which used process_create/3 to start swipl.exe

process_create from test.pl 
    process_create(SWIPL,
                   [ '-f', 'none',
                     '-t', 'halt',
                     '--no-packs',
                     '-p', POpt,
                     '-g', Goal,
                     Script
                   ],
                   [ stdout(pipe(Out)),
                     stderr(pipe(Out)),
                     cwd(PkgDir),
                     process(Pid)
                   ]),

Had Claude code
fetch: https://github.com/SWI-Prolog/swipl-devel/blob/ff5d52cf236c5468f344f3e4ad163de787805de8/tests/test.pl

which actually helped Claude in other ways such as using absolute_file_name/2 and concurrent_forall/3

While the test cases are working they are not working with other test cases, e.g. the output is not in one unified report, the test are working to confirm the predicates are working as expected.

5

A nicer route is probably to add cleanup/close code to library(persistency). I do not see a lot of use cases besides testing, but who knows …

6

i thought the command is db_detach() and you can give parametres in the attach clause with sync() : db_attach( D3 , [ sync(close) ] ).

after studiyng the persistency for a few days i started using it in its original form, from what persistency writes to a file , i transfer to other files ( after db_detach ) , in this way i create a very big prolog database system without having to use postgress or rocksDB :grinning_face: :+1: