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

spell check, update a few notes

Browse Source 
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@5582 57a11ea4-9604-0410-9ed3-97b8803252fd
This commit is contained in:
Linas Vepstas 2001-10-12 16:44:14 +00:00
parent 1506523cf6
commit 8610f39a58
1 changed files with 30 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
src/backend/postgres/README
View File

@ -130,7 +130,7 @@ password, *NOT* your unix login name and password.
Note that you (or your SQL database admin) will have to make sure Note that you (or your SQL database admin) will have to make sure
that access permissions on the various GnuCash tables have been set that access permissions on the various GnuCash tables have been set
appropriately. Typically, this will be by starting the 'psql' appropriately. Typically, this will be by starting the 'psql'
shell, listing all relations with \z, and then issueing shell, listing all relations with \z, and then issuing
a 'GRANT ALL on gncAccount TO someuser;', and so on, for each a 'GRANT ALL on gncAccount TO someuser;', and so on, for each
relation. Failing to do this will result in lots of unhappiness. relation. Failing to do this will result in lots of unhappiness.
The sysadmin will also need to make sure that TCP/IP connections The sysadmin will also need to make sure that TCP/IP connections
@ -149,15 +149,18 @@ mode=multi-user
The first two are single-user access modes. These are the The first two are single-user access modes. These are the
'safest' modes to use if you don't need multi-user capability. 'safest' modes to use if you don't need multi-user capability.
The single-update mode is strongly preffered over single-file. The single-update mode is strongly preferred over single-file.
(single-file can loose your data if your sql connection dies (The single-file mode is strongly deprecated, and can lead to
at unexpected times). to massive data loss under certain circumstances: for example,
if your sql connection dies after all the old data has been
deleted, but before the new data has been written out. Bluntly:
DO NOT USE mode=single-file. You won't be sorry.).
The multi-user modes are intended for use when multiple users The multi-user modes are intended for use when multiple users
need to view and make changes to the data. The default mode need to view and make changes to the data. The default mode
is multi-user. is multi-user.
If you have many users (more than a helf-dozen or so), you may If you have many users (more than a half-dozen or so), you may
want to run in multi-user-poll mode, instead of the default want to run in multi-user-poll mode, instead of the default
multi-user. This will stop the automatic updates of the multi-user. This will stop the automatic updates of the
local instance of gnucash, and thus reduce the amount of local instance of gnucash, and thus reduce the amount of
@ -178,7 +181,7 @@ You can alternate between multi-user and single-user modes for
the same database. Just be sure that all users have logged off, the same database. Just be sure that all users have logged off,
otherwise gnucash won't let you log on in single-user mode. otherwise gnucash won't let you log on in single-user mode.
Users are 'logged off' automatically when they exist gnucash. Users are 'logged off' automatically when they exist gnucash.
In case they have crashed, (and thus apear to still be logged In case they have crashed, (and thus appear to still be logged
in), you can log them off manually by issuing the following: in), you can log them off manually by issuing the following:
echo "UPDATE gncsession SET time_off='NOW' WHERE time_off = 'infinity';" | psql dbname echo "UPDATE gncsession SET time_off='NOW' WHERE time_off = 'infinity';" | psql dbname
@ -186,7 +189,7 @@ echo "UPDATE gncsession SET time_off='NOW' WHERE time_off = 'infinity';" | psql
Hopefully, you do not need to be warned that this dangerous Hopefully, you do not need to be warned that this dangerous
if there really are other users logged in. Accessing the if there really are other users logged in. Accessing the
database in single-user mode when there are other users logged database in single-user mode when there are other users logged
in will result in thier work being clobbered. in will result in their work being clobbered.
Other Options Other Options
------------- -------------
@ -219,7 +222,7 @@ at least for medium datasets (measured at 3.5 seconds on a 700MHz
Athalon a dataset with 3K transactions and 150 accounts, vs. 4.8 Athalon a dataset with 3K transactions and 150 accounts, vs. 4.8
seconds loading from file; postgres version 7.1.2). seconds loading from file; postgres version 7.1.2).
Hitting the 'save' button is a no-op and takes no cpu cycles. Hitting the 'save' button is a no-op and takes no CPU cycles.
(date is saved as its modified, so a global save is not needed). (date is saved as its modified, so a global save is not needed).
'exit' will stall for a few seconds, while a 'vacuum analyze' is 'exit' will stall for a few seconds, while a 'vacuum analyze' is
@ -239,7 +242,7 @@ But to load only a subset is hard, in several ways. First, its
technically hard to figure out what subset to load. Then, once technically hard to figure out what subset to load. Then, once
this is done, it takes about 12 millisecs to load one transaction this is done, it takes about 12 millisecs to load one transaction
when loading them one at a time (on an Athalon 700MHz). This is when loading them one at a time (on an Athalon 700MHz). This is
about 75 transactions a second. Of this, 90% of the cpu cycles about 75 transactions a second. Of this, 90% of the CPU cycles
are burned in the postgres server, so 'basic' tuning won't do are burned in the postgres server, so 'basic' tuning won't do
the trick ... some different algorithm is needed. the trick ... some different algorithm is needed.
@ -265,24 +268,28 @@ access).
-- Wire in the GUI to ask user for username/password to log onto the -- Wire in the GUI to ask user for username/password to log onto the
server. (GUI already implemented, just not yet used). server. (GUI already implemented, just not yet used).
-- The correct url format for username-password should be: -- The correct URL format for username-password should be:
postgres://username:passwd@host:port/dbname?key=value&key2=val2 postgres://username:passwd@host:port/dbname?key=value&key2=val2
However, the username-password part of teh URI is not correctly However, the username-password part of the URI is not correctly
parsed at the moment. parsed at the moment.
-- distinguish between 'save' and 'save-as' in gnc-book & backend. -- distinguish between 'save' and 'save-as' in gnc-book & backend.
If user hits 'save' in the single-user or multi-user mode, it If user hits 'save' in the single-user or multi-user mode, it
should be a no-op (since the saves have already occured). Only should be a no-op (since the saves have already occurred). Only
a 'save-as' requires a from-scratch sync. a 'save-as' requires a from-scratch sync.
-- add version number to the DB, so that new sql db's can be -- document how to use the version/extension tables to allow
auto-upgraded if table schema change. seamless upwards compatibility in the face of database schema
changes.
-- clear up end/destroy semantics. After book_end is called, -- clear up end/destroy semantics. After book_end is called,
its not possible to start a new session, since there are its not possible to start a new session, since there are
uninitialized pointers. Unless to book is deleted immediately, uninitialized pointers. Unless to book is deleted immediately,
everything is hosed. This is a generic backend design problem, everything is hosed. This is a generic backend design problem,
not just an sql backend problem, that needs fixing. not just an sql backend problem, that needs fixing.
(??? Maybe this has been fixed now, in the redesigned
gnc-book/gnc-session code ??? Maybe we just need to cleanup in
the postgres backend ??)
-- allow user to enter URL in GUI dialog. User can currently type URL -- allow user to enter URL in GUI dialog. User can currently type URL
into the file dialog window; it would be nice to have something into the file dialog window; it would be nice to have something
@ -297,14 +304,10 @@ access).
grep for all PERR's that don't set backend error. grep for all PERR's that don't set backend error.
-- note that transaction commit errors may in fact be i/o errors. -- note that transaction commit errors may in fact be i/o errors.
If an i/o error occured during commit, there would be some If an i/o error occurred during commit, there would be some
abberant rollback behaviour. Ouch. aberrant rollback behavior. Ouch.
-- the transaction rollback code needs to be a gui popup... -- the transaction rollback code needs to be a GUI popup...
-- fix the annoying postgres:,,localhost,asdf file syntax: needs
mods to gnc-book to keep it happy about lock files & such.
(coord with rlb on gnc-book redesign)
-- review (actually, design & architect) the communications error -- review (actually, design & architect) the communications error
handling policy. For example, CopyToEngine() will leave handling policy. For example, CopyToEngine() will leave
@ -335,11 +338,11 @@ To Be Done, Part II
This list only affects the multi-user and advanced/optional features. This list only affects the multi-user and advanced/optional features.
Most of the items on this list are 'good-to-fix' but are not Most of the items on this list are 'good-to-fix' but are not
truly critical. They may result in abberations, but general truly critical. They may result in aberrations, but general
operation is probably OK. operation is probably OK.
-- when an account is edited, price lookups happen *twice* !! -- when an account is edited, price lookups happen *twice* !!
once when opend for edit, and again when committed !! once when opened for edit, and again when committed !!
(the first one is due to gnc_account_tree_refresh () (the first one is due to gnc_account_tree_refresh ()
called by gnc_account_window_create() near dialog-account.c:1642) called by gnc_account_window_create() near dialog-account.c:1642)
@ -351,7 +354,7 @@ operation is probably OK.
seconds ... doing this uniformly can cut down on sql traffic. seconds ... doing this uniformly can cut down on sql traffic.
(This is particularly egregious for price queries). Implement this (This is particularly egregious for price queries). Implement this
by putting a datestamp in along with the version number. Let by putting a datestamp in along with the version number. Let
the backend check the datastamp, and if its aged less than the backend check the datestamp, and if its aged less than
15 seconds, skip doing the sql query.) 15 seconds, skip doing the sql query.)
DONE --- but we need to detect redundant price queries .. ughh DONE --- but we need to detect redundant price queries .. ughh
@ -412,7 +415,7 @@ operation is probably OK.
of the wrong version. of the wrong version.
-- pgend_transaction_commit does it correctly; but the GUI doesn't -- pgend_transaction_commit does it correctly; but the GUI doesn't
report a rollback. (need to get err message out of engine, into report a rollback. (need to get err message out of engine, into
gui). GUI).
-- pgTransactionSync() is broken, but its not used anywhere. -- pgTransactionSync() is broken, but its not used anywhere.
-- pgend_account_commit checks version but doesn't rollback. -- pgend_account_commit checks version but doesn't rollback.
(nor does the GUI report a rollback.) (nor does the GUI report a rollback.)
@ -455,9 +458,9 @@ operation is probably OK.
I think it might be better to leave this unbalanced, and just I think it might be better to leave this unbalanced, and just
plain force everything in the database to be balanced. In this plain force everything in the database to be balanced. In this
case, we should then modify the code to check for unbalanced case, we should then modify the code to check for unbalanced
transactions before commiting them, or otherwise force the backend transactions before committing them, or otherwise force the backend
to run in balanced mode. We could set 'force_double_entry=2' to run in balanced mode. We could set 'force_double_entry=2'
but this is currently unimplmented in the engine. Alternately, but this is currently unimplemented in the engine. Alternately,
we could call 'Scrub' at appropriate times. we could call 'Scrub' at appropriate times.