On Tuesday 09 August 2005 9:10 am, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > 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, no. > > Also keep in mind that the logs are not complete and don't store > enough information.
It's becoming clear that my original QOF undo idea would be similarly incomplete, albeit in different areas. > It would be much better if QOF had an in-core > "log" that it could use instead of depending on the existing file-log > interface. Personally I'd like to rip out the file logs... They > cause way too many problems. :( I wish I'd never mentioned undo . . . . - this is going to take time. > >> 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? > > I suspect if you keep the last 300 _operations_ (where an import is > one operation) then yes, that would probably be sufficient. :) If, > however, it's only 300 changed entities, that might NOT be sufficient. (I wasn't even thinking of storing an entire import in undo at this stage!) :-( That would probably need a branch off the list - one pointer on the list to either a second list from the import or some other collation of the import changes. (And yes, I was thinking of a simple 300 changes - but without an undo for imports then importing data would have probably required the deletion of the previous undo list (as it may reference entities changed in the import) upon completion of the import commit. That, I accept, would not be workable.) > >> 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? > > No, I don't think so. I think it should still use the begin/commit > edit hooks. OTOH, I'd also like some way to combine multiple > begin/commit blocks into single events (e.g. "import") so that you can > undo the full import all at once. This is *definitely* getting too much for me at this time. I'm afraid I cannot promise to meet those requirements / expectations. Undo may have to go on the back burner until next year. Sorry. Ah well, at least I asked. QOF undo is, if I may quote, a "simple matter of programming". Unfortunately, it is programming that I do not have time to do myself, yet. I *might* investigate a very limited undo strictly within CashUtil, just as a framework, that allows only the current entity edits to be undone during the operation of the current sub-shell. It may throw more light on how the QOF version could operate and lay some foundations that I can work on later within QOF and thereby GnuCash. For now, I'm afraid, I have to step back and keep to what I can realistically hope to complete. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpe9RCKrq3yF.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
