r21517 - gnucash/trunk/src/libqof/qof - Add is_readonly
jralls at ceridwen.us
Sat Nov 5 16:28:03 EDT 2011
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
>>> 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
> 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.
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))
874 uh_oh = FALSE;
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.
More information about the gnucash-devel