allow SESSION_READ_ONLY open a DBI book without write privileges

[Geert Janssens]

Fedora 29 is quite old by now...

Op maandag 13 juli 2026 02:28:16 Midden-Europese zomertijd schreef Derek Atkins:
> Maybe that was the issue.
> 
> [root at code ~]# rpm -q doxygen
> doxygen-1.8.14-7.fc29.x86_64
> 
> -derek
> 
> On Sun, July 12, 2026 2:10 pm, John Ralls wrote:
> > Derek,
> > 
> > That doesn’t square with the last build being two years ago, we removed
> > auto tools in 2017. https://github.com/Gnucash/gnucash/pull/1943, which
> > was merged immediately after the last successful docs build is the
> > culprit. What version of Doxygen are you running?
> > https://github.com/Gnucash/gnucash/pull/1943/changes/891b921c811f32e214fe9
> > fc1a87e392b58ed7757 bumped the Doxyfile version from 1.8.3 to 1.9.7.
> > 
> > Regards,
> > John Ralls
> > 
> >> On Jul 11, 2026, at 18:08, Derek Atkins <derek at ihtfp.com> wrote:
> >> 
> >> Yes, doxygen not building is a known issue.  The build requirements
> >> changed and I've never spent the time to figure out how to update the
> >> script to meet the new requirements.  Specifically I used to be able to
> >> build the doxygen.cfg manually by calling the Makefile.am with the right
> >> rule.  But that was removed for CMake, and I think to get that to work I
> >> might need to install a complete build system, which I kinda don't want
> >> to do.  Worst case I'll have to make VM just for that..  But it just
> >> hasn't been high on my priority list.
> >> -derek
> >> Sent using my mobile device. Please excuse any typos.
> >> 
> >> On July 11, 2026 16:18:15 John Ralls <jralls at ceridwen.us> wrote:
> >>> Noah,
> >>> 
> >>> Please always copy one of the mailing lists when you email one of the
> >>> GnuCash developers unless it’s to send something like a GnuCash book;
> >>> in that case the email should just have the file, all of the discussion
> >>> around it should be copied to the list.
> >>> 
> >>> I’ve passed on to Derek via IRC the Doxygen-docs problem just in case
> >>> he misses it here.
> >>> 
> >>> Yup, readonly-mode is largely cosmetic and applied only to the GUI.
> >>> GnuCash is not designed for use by more than one user at a time and
> >>> read-only mode is very simplistic.
> >>> 
> >>> I don’t think it would be too hard to extend its force to the backend
> >>> so that a read-only session is blocked from writing. But if you want a
> >>> read-only session to lock the database then it’s not really read-only
> >>> anymore.
> >>> 
> >>> How about leveraging the database’s locking? Wrap all of the queries
> >>> with dbi_conn_transaction_begin and dbi_conn_transaction_commit. That
> >>> will make multi-table writes atomic with an exclusive lock, blocking a
> >>> reader from reading them until the whole write is complete, while a
> >>> read query while loading will block the exclusive write lock until the
> >>> read is complete.
> >>> 
> >>> Regards,
> >>> John Ralls
> >>> 
> >>>> On Jul 11, 2026, at 12:24 PM, array_hourly_0u at icloud.com wrote:
> >>>> 
> >>>> Thanks for merging #2264 and #2266 John.
> >>>> 
> >>>> Arrg.  As I've started to poke more into this read-only and lock
> >>>> topic, I've found some surprises and ultimately a correctness matter.
> >>>> 
> >>>> What SESSION_READ_ONLY actually means
> >>>> ------------------------------------------------------------
> >>>> 
> >>>> 1. At the engine level, SESSION_READ_ONLY doesn't actually enforce
> >>>> read-only. The mode only affects lock handling -- it does not mark the
> >>>> book read-only. Book write-protection is applied separately by the GUI
> >>>> only, which calls qof_book_mark_readonly() after opening. I confirmed
> >>>> with an API bindings test that a SESSION_READ_ONLY session can still
> >>>> edit an account and have the change persisted to the SQL store. So an
> >>>> API/bindings consumer that opens SESSION_READ_ONLY expecting the book
> >>>> to be unwritable does not get that guarantee unless it also calls
> >>>> qof_book_mark_readonly() itself. [a bug if one interprets
> >>>> SESSION_READ_ONLY reading the enum name while not carefully parsing
> >>>> the header comments ]
> >>>> 
> >>>> 2.  SESSION_READ_ONLY ignores the lock. A read-only consumer opens a
> >>>> book even while another process holds it open, perhaps mid-write,
> >>>> which is exactly when the state can be inconsistent; and because the
> >>>> SQL backend commits incrementally, a reader can catch a
> >>>> partially-applied edit. [ a read-only client correctness bug ]
> >>>> 
> >>>> So today the mode neither protects read consistency (it ignores the
> >>>> lock) nor guarantees read-only-ness (that's a GUI add-on), even though
> >>>> the name implies both.
> >>>> 
> >>>> Proposed path forward
> >>>> -----------------------------------
> >>>> 
> >>>> For building read-only tools on the API, what I'd want is a read-only
> >>>> session mode that (a) takes the lock, so a writer cannot be active
> >>>> while the tool reads, and (b) actually enforces no writes.
> >>>> 
> >>>> A possible direction would be to replace SESSION_READ_ONLY with two
> >>>> modes whose names state what they do, and have both mark the book
> >>>> read-only so enforcement is intrinsic rather than GUI-only:
> >>>> - SESSION_READ_ONLY_EXCLUSIVE -- takes the lock (fails if the book is
> >>>> already locked); for tools that need a consistent, uninterrupted read.
> >>>> Calls qof_book_mark_readonly(). Obviously a SQL backend user would
> >>>> need sufficient permissions to take the lock.  I'd want to add some
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20260713/ad410cfe/attachment.htm>