Connecting to a postgresql Database on the Local machine

[Neil Williams]

On Saturday 26 March 2005 10:25 pm, Josh Sled wrote:
> http://cvs.gnucash.org/docs/HEAD/ has the generated doxygen docs from
> the source tree; additions here -- as close to the code as possible --
> are welcome.

There's also documentation for the Gnome2 port codebase:
http://code.neil.williamsleesmill.me.uk/gnome2/

Our doxygen output online is HTML only. HOWEVER, you can create other output 
formats yourself from the source tree. See the Doxygen site for settings in 
the doxygen config file to render XML, LaTeX and other formats.

> There's a bunch of high-level documentation about gnucash in various
> files in the source tree; these should be vetted, edited, and moved over
> into the doxygen stuff over time.

This is a short list of those files in the current source tree:
http://code.neil.williamsleesmill.me.uk/otherdocs.html#GNUCASHDOCS

> qof.sourceforge.net has the source and documentation for QOF.

That's quite old now, I haven't got access to update it, but I've got an 
updated version online:
http://code.neil.williamsleesmill.me.uk/doxygen/

> > > 3. I hope the relational database interface will not be intentionally
> > > disabled because:
> > > A. Using a relational database should force a decent object oriented
> > > data design upon the developers.

I don't believe that this could ever be completely accurate. There will always 
be compromises.

Those who see the objects as more important than the storage will favour 
multiple generic backends, some relational some not. These could be termed 
'application developers who use a database, sometimes.'

Those who see the storage as more important than the objects will favour 
multiple *frontends* (Gtk, Qt, Perl, ...). These people could be termed 
'database developers who use an application, sometimes.'

GnuCash is an application with one front end and multiple backends. A lot (the 
majority?) of the current developers may well identify more with the idea of 
the needs of the application overriding the needs of the database.

There can be no force. A backend can influence but not dictate to the front 
end. The only question is what *you* term the front end. Me, I see the front 
end as Gnome2 and the backend as whatever suits the need best at that time. 
We've been using XML and I think we are correct to move on from that as our 
long term storage and use it instead for data interchange. So 
GnuCash-backend-file-v2 XML will always be around and will need to be read 
for some time. QSF XML will (hopefully) serve our needs to export, import and 
exchange data between users and between applications. Sqllite is the current 
target for the backend to replace the current XML.

> >
> > I've seen horrendous data-models that are still relational, and
> > appropriate object models that don't translate easily into relational.
> >
> > <<<<<<<<<<<
> > That's unfortunate.

It's a question of which is the host and which is the plugin. GnuCash - as a 
Gnome application written in C and Scheme and having more than one storage 
mechanism, must be the host. The plugin, therefore, is the database. To 
expect the database design to dictate structure to an established application 
that already has other backends to use is getting to the point of the tail 
wagging the dog!

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- 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-user/attachments/20050327/3c0c92b6/attachment.bin