CLI undo edit?

[Neil Williams]

On Tuesday 09 August 2005 9:10 am, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050809/188695c4/attachment.bin