mirror of
https://github.com/Gnucash/gnucash.git
synced 2025-02-16 18:25:11 -06:00
46 lines
1.7 KiB
Plaintext
46 lines
1.7 KiB
Plaintext
/** \page engine Engine Framework
|
|
|
|
API: \ref Engine
|
|
|
|
Additional engine API documentation can be found in the src/doc/design/engine.texinfo file.
|
|
|
|
This file contains some extra meta-information that is not directly relevant
|
|
to the API documentation.
|
|
|
|
\section firstclass First Class Objects (C structs) vs. Storing Data in KVP Trees
|
|
|
|
API: \ref KVP
|
|
|
|
Suppose you have a neat idea for a new feature for the GnuCash engine.
|
|
Should you create a C structure (a "first class object") and all
|
|
of the required machinery for it (e.g. an SQL backend), or should you
|
|
just put all of the data in a suitable KVP (Key Value Pair) frame
|
|
somewhere?
|
|
|
|
The answer depends on whether the concept requires extensive
|
|
pointer chasing between different types of existing C structs,
|
|
or whether it more naturally can hang with some existing object.
|
|
|
|
If it seems to be an independent concept, it can still be placed
|
|
in the KVP tree of the book, which gives it a 'top-level' existence.
|
|
|
|
If the concept is used only infrequently, then it probably belongs
|
|
in a KVP tree. If the concept has performance-critical requirements,
|
|
then it is better to implement it as a C struct, and similarly
|
|
design an appropriate SQL table around it, so that the database
|
|
can be queried efficiently and rapidly.
|
|
|
|
\subsection terms Terminology:
|
|
|
|
- First-class object: something that has a C struct associated with it,
|
|
and has its own specialized backend infrastructure for storing/querying
|
|
it.
|
|
|
|
- Second-class object: something that lives entirely in a KVP tree.
|
|
Note, however, that not all data in a KVP tree deserves to be called
|
|
an 'object'. Some things in a KVP tree are merely 'attributes'.
|
|
If you push on this point, there is indeed a gray area between
|
|
second-class objects and attributes.
|
|
|
|
*/
|