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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
