Dirty entity identification.

[Neil Williams]

On Friday 22 July 2005 2:33 am, Chris Shoemaker wrote:
> > I think it's risky to offer option 2 without some kind of fallback - what
> > if the server is actually local and the problem is a sign of something
> > more serious - the user's system has become unstable etc.? Alternatively,
> > the user might just need to do something else and cannot keep GnuCash
> > running until the server comes back online.
>
> That doesn't sound very good.

? The user has to make that decision. If the backend is designed to go on and 
offline then the QofBackend can deal with that. This would only come into 
play when the user expects a save/commit and an error is reported. As an 
option in that error dialog, the user needs some way of saving the changes 
they have made so far - in case it IS a major fault with the server. GnuCash 
cannot always detect that, neither can QOF, only the user has that 
information.

> You're describing the worst-case scenario.  Going offline is not
> necessarily an error condition.

Yes, I'm only concerned with the error condition - a complete failure in the 
connection. Everything else is backend-specific because only certain backends 
can ever support incremental backups, partial data or remote connections.

> Many frontend/backend systems are 
> *designed* to do this as a regular part of operation.  For those
> systems, the solutions you describe are not acceptable.

Those would not report an error, they are designed to operate that way. If the 
backend repeatedly fails to communicate with it's own server, it will have to 
report an error eventually and this fallback would be available.

The backend mechanism is generic - it has to deal with each backend equally 
and let the backend do what it can do best.

> It may be 
> impossible to save everything to a local file, because client may have
> only the portion of the data that he was editing/viewing.

Then the book is a partial book and can be saved to QSF. The user cannot be 
left dangling with no way to recover data entered after a remote connection 
went down.

> And how often would we resend the entire collection of splits?

Only in case of a resumption after an error condition and only under direct 
user control.

> > >   4) We do a tree search that finds that only one Account is marked as
> > > "contains dirty Splits" so our linear search through Splits is only
> > > through that Account's Splits instead of all Splits.  We find the
> > > changes and commit them.
> >
> > To me, this is doing the work of the backend in the UI.

A backend that is customised to handle incremental backups and partial data 
will be able to identify the modified instances using last_update without 
EVER knowing anything about this "tree" that simply doesn't exist.

There is NO tree. (I wish I'd said that the first time you mentioned it - note 
to self, do as Derek advised and NEVER allow any use of "tree" again!)

> > Remember, the 
> > backend
>
> You're saying the frontend doesn't need to know which instances are dirty?

? No, I'm saying that the backend can do it's own thing, including on and off 
cycles if it supports those.

The backend does not understand an Account. It has no concept of a Split. They 
are all just objects. The backend cannot do a tree search, no tree exists. As 
I showed in the previous message, the source code HAS no tree - it only 
exists in the human mind, the UI and the docs.

There is NO direct relationship between an Account and it's Transactions.
None. Zip. No engine call can go from an Account to a Transaction, the source 
code is simply not built to support that, neither does it need to.

Accounts know about their Splits and Splits know about Transactions and 
Accounts. Transactions know nothing of Accounts and Accounts know nothing 
about Transactions.

The engine knows NONE of this. All the engine cares is that there are three 
objects and N parameters. What the engine doesn't know, the backend cannot 
understand and the book cannot find.

That is why QOF can be spun-out as a generic framework, it has had all the 
financial objects, all the human concepts and all the specific relationships 
stripped out. It treats every entity the same way, everything is equal, no 
hierarchy exists of any kind.

In some ways, I regret using the term book - it implies a structure with a 
cover, a table of contents, an index, chapters and page numbers that simply 
does not exist. In reality, it's closer to a tombola: lots of coloured balls 
with numbers stamped on them, each one identical to all the others in all 
other respects. Balls of the same colour are attached to each other 
(collections) which is where the analogy breaks down.

> Well, the functions in the engine know that an Account has a list of
> splits.

No, they do not. The engine code does not know anything called an Account or a 
Split. All it knows is that one object contains a pointer to another object 
using a parameter identified using a particular static string. Some 
parameters are strings, or integers or booleans etc. Until v.recently, no 
object contained a list of anything, as far as the engine was concerned - 
there was no parameter that could express a list of other objects.

At no point does the engine have any concept of a Split or an Account or any 
other human concept. It's all just objects and parameters. That's it.

> > The tree is too specific - QOF is generic and does not get into the
> > specific conceptual relationships.
>
> In your view, where exactly are those relationships best represented?

1. The UI display
2. The docs
3. The minds of the developer and the user.

There is no place for specific conceptual relationships in the engine, the 
backend, the book or the session.

-- 

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/20050722/41a4e757/attachment.bin