Possible bug in library persistency?

Help!
1

I have this code in a file 001.pl:

#!/usr/local/bin/swipl -s

:- use_module(library(persistency)).

:- persistent m:p(x:any).

part1 :- m:( db_attach( ‘db.txt’,), assert_p(1)).

part2 :- m:( db_detach, assert_p(2)).

And how I use it:

$ ./001.pl
Welcome to SWI-Prolog (threaded, 64 bits, version 9.3.20-DIRTY)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- part1.
true.

$ cat db.txt
created(1757350507.4964447).
assert(p(1)).

?- part2.
ERROR: db_file `m’ does not exist
ERROR: In:
ERROR: [20] throw(error(existence_error(db_file,m),_170))
ERROR: [18] persistency:persistent(m,assert(p(2))) at /usr/local/lib/swipl/library/persistency.pl:471
ERROR: [16]
ERROR: [15] with_mutex(‘$persistency’,db_assert_sync(m: …))
ERROR: [11] toplevel_call(user:user:part2) at /usr/local/lib/swipl/boot/toplevel.pl:1319
ERROR:
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.
?- m:p(X).
X = 2.

After db_detach, p(X) is empty, as expected, a subsequent assert_p(2)) raises an exception but fills the 2 into p(X).

I think this is a bug. It should not fill in something.

Thanks in advance, Frank Schwidom

3

These are IMO not really bugs, just invalid usage that is not handled properly. It is an old library … But yes, it is still relevant. If anyone wishes to update the docs and/or improve error handling, please file a PR. Please note that such improvements should not cause significant slow down or make the code too hard to read.

Note that the ordering is hard. First assert/1, then update the journal has the advantage that it keeps the journal consistent if a limit or permission causes the assert to raise an error. Note that it might work safely by using transaction/1. Not sure how much impact that has on performance, but probably not too much.

1 Like