IntenseFinance/gnucash
3
0
Fork 0
mirror of https://github.com/Gnucash/gnucash.git synced 2025-02-25 18:55:30 -06:00
Code Issues Packages Projects Releases Wiki Activity

notes about consistent updates

Browse Source 
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@786 57a11ea4-9604-0410-9ed3-97b8803252fd
This commit is contained in:
Linas Vepstas 1998-04-05 10:49:16 +00:00
parent 3376aa8648
commit 2cdff16c92
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
src/engine/design.txt
View File

@ -122,25 +122,30 @@ pthread_getspecific() to define a per-thread global and/or ring/queue.
Engine Isolation
----------------
Goals of engine isolation:
o Hide the engine behind and API so that multiple, plaggable engines
could be created, e.g. SQL or CORBA.
o Engine users are blocked from being able to put engine ineternal
structures in an inconsistent state. Updates are "atomic".
Some half-finished thoughts about the engine API:
-- The engine structures should not be accessible to any code outside of the engine.
Thus, the engine structures have been moved to AccountP.h, TransactionP.h, etc.
-- The engine structures should not be accessible to any code outside
of the engine. Thus, the engine structures have been moved to
AccountP.h, TransactionP.h, etc.
The *P.h files should not be included by code outside of the engine.
-- The goal of hiding the engine internals behind an API is to allow the engine
to be replaced by a variety of back ends, e.g. an SQL and/or CORBA back-end.
-- The down-side of hiding is that it can hurt performance. Even trivial data
accesses require a subroutine call. Maybe a smarter idea would be to leave
the structures exposed, allow direct manipulation, and then "copy-in" and
"copy-out" the structures into parallel structures when a hidden back end
needs to be invoked.
-- the upside of hiding behind an API is that the engine can be instrumented
with extension language (perl, scheme, tcl, python) hooks for pre/post processing
of the data. To further enable such hooks, we should probably surround all
operations on structures with "begin-edit" and "end-edit" calls.
-- the upside of hiding behind an API is that the engine can be
instrumented with extension language (perl, scheme, tcl, python) hooks
for pre/post processing of the data. To further enable such hooks, we
should probably surround all operations on structures with "begin-edit"
and "end-edit" calls.
-- begin/end braces could potentially be useful for two-phase commit schemes.
where "end-edit" is replaced by "commeit-edit" or "reject-edit".