On Monday 08 August 2005 9:47 am, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > If the undo list is retained within the book and only referenced from > > that book, this would provide sufficient segregation. > > I presume by "retained" you mean "in core" and not "in storage"...
Yes, the list itself would be part of the QofBook struct and accessed via an API exposed via qofbook.h - the undo list itself could be stored in a similar manner to the current logs if that was useful. Depends on the SQL backend - if we're all using immediate commit in SQL then would there be any need for the logs at all? > IMHO the undo/redo list should be size-bounded, not unlimited. I was wondering about that too. So a hard-coded limit of, say 300 - should that be configurable? or an absolute limit and configurable only downwards? > Also, it should not necessarily depend on the dirty flag. Maybe it would use the event interface instead - every modify or create event would be added to the undo list? Should the name reflect that? void qof_book_undo_event(QofBook *book); ? or just void qof_undo(QofBook *book); ? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpo4qqeFGN02.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
