r21517 - gnucash/trunk/src/libqof/qof - Add is_readonly

[John Ralls]

On Nov 5, 2011, at 1:31 AM, Christian Stimming wrote:

> Hi John,
> 
> Am Freitag, 4. November 2011 schrieb John Ralls:
>>> Trac: http://svn.gnucash.org/trac/changeset/21517
>>> 
>>> Modified:
>>>  gnucash/trunk/src/libqof/qof/qofsession-p.h
>>>  gnucash/trunk/src/libqof/qof/qofsession.c
>>>  gnucash/trunk/src/libqof/qof/qofsession.h
>>> 
>>> Log:
>>> Add is_readonly attribute to QofSession class.
>> 
>> Why do we need this? QofBook already has a read-only attribute which
>> prevents even editing instances, so there shouldn't ever be anything to
>> save in a read-only session.
> 
> I've seen the read-only attribute in QofBook. However, it is not sufficient. 
> 
> My goal is to implement a "read-only" operation mode of gnucash, so that our 
> infamous "The database is locked" dialog offers the choice "Open read-only" 
> (instead of or additionally to "Open anyway").
> 
> For this, the read-only attribute needs to be stored in the same place as the 
> database URL. That one is stored in QofSession, so the fact it's a read-only 
> URL needs to be stored in QofSession, too.
> 
> Also, the fact that it's read-only needs to be stored already during 
> qof_session_begin(), but at that time, no QofBook exists so far. The 
> QofBook(s) won't be created before qof_session_load, but at that point the 
> read-only attribute needs already be decided upon. So that's another reason 
> for this addition.
> 
> In my planned feature, if the QofSession is read-only == TRUE, all of the 
> QofBook(s) inside that session will also have read-only == TRUE.
> 
>> If there are leaks in QofBook's read-only
>> block, fix that. It's not a good plan to let the user do a bunch of edits
>> and then say "Oops, this session is read only, so you can't save your
>> work!"
> 
> Both are needed, and both will have the same value - for this use case. There 
> might be other use cases where the QofSession is read-write but (one of) its 
> QofBook(s) is not.

Christian,

That's an excellent idea, but I think you need to re-analyze the code a bit. In particular, this section of src/gnome-utils/gnc-file.c, in gnc_post_file_open():

870        if (uh_oh && (io_err == ERR_SQL_DB_TOO_OLD ||
871                      io_err == ERR_SQL_DB_TOO_NEW))
872        {
873            qof_book_mark_readonly(qof_session_get_book(new_session));
874            uh_oh = FALSE;
875        }

This is the *same function* that displays that dialog box. All that you need is a button on the dialog box to set a local variable in that function and add the variable as a condition to the above conditional and you're done.

While QofSession has facilities for multiple books, it really only made sense to do that in the old "gemini" book-closing scheme, which was never fully implemented (and a large part of which I removed over the summer) -- and in any case it allows only one open/active book (qof_session_get_book() doesn't return a list). What use-case do you have in mind that would need multiple books in a session, especially multiple *active* books? 

What you implemented contemplates a situation where the (a?) book is writable but the session isn't, so the user has been allowed to make edits but is blocked from saving them. What possible use-case would make that acceptable? 

qof_session_safe_save() is for upgrading the sql database in place. I can understand that if the file/session/db is to be read-only that that should be blocked, but that can be accomplished inside of gnc_post_file_open(), the only place that safe_save() is called.

Regards,
John Ralls