postgres development

[Matthew Vanecek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 5 Mar 2003, Andrew Pimlott wrote:

> On Mon, Mar 03, 2003 at 10:36:20PM -0600, Matthew Vanecek wrote:
> > On Mon, 3 Mar 2003, Andrew Pimlott wrote:
> > 
> > > I've seen messages that at least one person is working on a redesign
> > > of the postgres back-end.  (I didn't check who, but I assume he's on
> > > the list.)  I'm thinking about a little project that would like to
> > > interface with gnucash at the data level; ie, talk to the database
> > > rather than use the gnucash API.  If anyone working on the postgres
> > > back-end has any concrete plans for it, I would appreciate hearing
> > > about them.  Perhaps I could offer some assistance as well.
> > > 
> > 
> > That probably is not a good idea, unless you are just going to use the 
> > database and no other part of Gnucash.  It's unsafe design--you could 
> > easily munge the data.
> 
> I would hope that the data model would be sufficiently normalized
> and constrained to make direct access reasonably safe.  I consider
> this is an entirely reasonable goal (and as I said, I would be
> interested in helping).

My data model is fine--I'm using a pretty standard one.  I've not yet 
modelled the business objects or scheduled transactions yet, though..ERDs 
are always accepted...

> 
> I am not (currently, at least) concerned with running my program
> concurrently with gnucash, so that is not an issue.  (Though
> hopefully it could be addressed if needed.  I realize that coherency
> between gnucash and the database is tricky.)
> 

Yeah.  It's gonna be a chore to keep Gnucash in line and behavin'! ;)

> > Is there some reason you cannot use the Engine 
> > API?  That would be a far better direction, and the Engine API is pretty 
> > well defined and separated from the GUI.
> 
> Maybe I will go back and give it another shot, but my early efforts
> were slow going.  This led me to decide that talking SQL would be
> easier.

Talking Engine would yield far more extensibility.  If you're just 
interested in talking SQL, then creating your own model would be more 
advisable.  Your welcome to do what you need with our code, of course.

My code is not yet to a point where I feel comfortable placing it in the 
public eye.  I have a very specific direction I'm headed, and have not 
progressed far enough down the road to let it out yet.  Unfortunately, 
work has been interfering more than usual in life, so coding time is 
becoming more precious....

- -- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+ZsXwi/CNzDSN0RIRAtcBAJ4xsgONCcGXVwcuAf3FYajEY/5b5QCfW26w
N8HpBnsQHZ0gtf9SvDFjSG0=
=QSCl
-----END PGP SIGNATURE-----