Connecting to a postgresql Database on the Local machine

[Josh Sled]

On Sat, 2005-03-26 at 16:33, ted creedon wrote:

> From: Josh Sled [mailto:jsled at asynchronous.org] 
> Sent: Saturday, March 26, 2005 12:55 PM

> On Sat, 2005-03-26 at 14:59, ted creedon wrote:
> 
> > 1. What business functionality is not supported with postgresql?
> 
> All of it.
> 
> <<<<<<
> So well documented....

? I don't understand.  What would be acceptable documentation, to you?

None of the business functionality is supported by the PG DB backend. 
There aren't tables for it, the PG backend doesn't know about it, it's
not persisted/restored, &c.  I'm sure this This has been mentioned on
the mailing list many times.

I notice that the FAQ didn't contain anything about the postgres DB
backend, though this question does come up quite a bit; I've just added:
http://gnomesupport.org/wiki/index.php/GnuCashFaq#Q:_Is_the_Postgres_DB_Backend_supported.3F


> The desire and intent is to use another means (generically connecting QOF to
> a DB backend) to provide database support.
> 
> This will require that scheduled transactions, at least but primarily, be
> "QOF"-ized; the business and other engine datatypes are already.
> 
> <<<Any written documentation?...

For what, exactly?

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 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.

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



> > 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've seen horrendous data-models that are still relational, and appropriate
> object models that don't translate easily into relational.
> 
> <<<<<<<<<<<
> That's unfortunate. My experience is just the opposite. In fact my summer
> interns are not allowed to code anything without:
> 1. User's manuals.
> 2. System Administrator's Manuals
> 3. Data Design
> 
> Done first....
> >>>>>>>>>>>>

My only point was that "force" is too strong a word on multiple levels:
we need to be forced, nor does it actually force anything to be true.

In any case, we welcome well-formed source patches; doing those other
things is your perogative.


> What would this accomplish?
> 
> <<<<<<<
> Arcane things like documentation, correctness....
> I know, "Its written in C and Scheme. Its self documenting."
> <<<<<<

At the end of the day, implementation is the only truth.  Too-detailed
design documentation, especially if seperate from the code, can quickly
and easily become out of date.  And certainly design docs and code can
be erroneous; in fact, they could both be incorrect, but in different
ways...

At the same time, it would be great to have more, and more correct,
documentation than we have now.  I'm a fan of data-driven and
declarative styles that need minimal -- or can function sufficiently as
-- documentation.


I think the best path to having a more understandable GnuCash is by
simplifying the code base so it doesn't require explanation, not by
adding more explanation.



> Good luck. At least I know what I'm working with. A good prototype with some
> interesting ideas.

That's unfair ... gnucash is certainly not a prototype just because it
doesn't have a feature you want, or behave the way you think it should.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`