Re: [Planner Dev] Database and its upgrade path.

[minus <minus toneby com>]

On Sun, 2005-05-15 at 02:15 +0300, Jani Tiainen wrote:
> minus kirjoitti:
> > Hi
> > 
> > I have managed to make my planner(cvs) use postgresSQL on a computer
> > running Debian unstable (last update 2005-05-14). It was a long and hard
> > trip :-(
> > 
> > First building planner was a hurdle because some gnome packagaes are at
> > 2.8.* and not at 2.10.0 as planner want them. (I cheated and changed
> > configure.in)
> 
> Well, this is not Planner issue. You can always compile newer libs by 
> yourself or wait until official 0.13 version appears in Debian. As you 
> may know, Debian is not fastes in it's moves...

Is there any known issues with using 2.8.*?  I know that 2.10.0 will
enter Debian when the release is out (It is in experimental right now)

> 
> > Next step was to create the database. Wasn't to hard but some steps
> > in the guide should change order (patch is in the works). In debian
> > there is a difference between the postgres user and other 'ordinary'
> > users.
> 
> And so it should be - it's more secure that way. Otherwise anyone could 
> create/remove databases as they wish. Malicious user could do a lot of 
> harm that way.

yes. but there was no mention in the planner sql readme about it.

> > I had a running binary, but what should I do now? I found the answer in
> > old mail's on the lists.
> > 
> > Step three: Get a working connection. All I got was (postgres.log)
> > 2005-05-14 10:13:31 [4207] LOG:  connection received: host=127.0.0.1
> > port=33127
> > 2005-05-14 10:13:31 [4207] FATAL:  IDENT authentication failed for user
> > "minus"
> > 
> > This one took time to find. I had to add a line in postgres's config
> > so I was a trusted user on all databases :-(
> 
> No you don't have to be. Just setup your databases and authentication 
> correctly. Still, this is issues with Postgres and maybe Debian, but 
> again, this is not Planner issue.
> 
> Line you might need in pg_hba.conf is:
> 
> local	sameuser	sameuser	127.0.0.1/32	trust
> 
> Meaning user named 'foo' is trusted to use database 'foo'.
> Of course you can use more complex authentication methods, groups etc. 
> but you have to set them up in Postgres configuration.

the default config had this:
host    all         all         127.0.0.1         255.255.255.255  ident
sameuser

which didn't work. I added:
host    all         minus       127.0.0.1         255.255.255.255  trust

which worked for me and is not too insecure.

> 
> > Step four:
> > In a new database the table property_global is empty! 
> > So planner crashed when checking database version.
> > fixed by:
> > insert into property_global (prop_name,value) values
> > ('database_version','0.13');
> > 
> > 
> > This little tripp got me to dive right into the hard of the sql stuff.
> > It were good but not very pleasant :-/
> > 
> > I think that the database upgrade part should be in a separate
> > application. (check out mantis www.mantisbt.org, their database upgrade
> > system is great). This would simplify the code greatly and it would be
> > easier to allow other databases (mysql). 
> 
> Well database backend is underway to be rewritten. For now you have to 
> deal what it is and it's pretty badly broken (you'll notice it later if 
> you really try to use it..) One of things is to have create/upgrade code 
> in separate application. Still it doesn't enable to use other than 
> Postgres since code inside (even it uses libgda) is built to use 
> Postgres only.

Has there been any (open) design discussion?

> There is some quick fixes coming to 0.14 to handle few things correctly. 
> Of course you can always welcome to give a hand.
The hand I'll keep. Some time you might get ;-)

minus