-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is maybe too confusing to have separate default driver/database for
db.* and v.* modules. First I thought, that in some cases
it could be useful, but usually both groups of modules use the same
database. Driver/database options can be used if necessary (v.in.db).
What do you think, should we remove v.database and use db.connect
settings also for vectors?
Radim
-------------------------------------------------------
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and schema.
I think that there is problem to connect a vector with a table in a schema
with v.db.connect.
db.login was added to 5.7. It can be used to set user and password
for driver/database.
WARNING: password is stored as text in $HOME/.grasslogin5
User and password from database definition (db.connect,v.db.connect) is
no more used.
This change was necessary to allow work in groups. Now it is possible
to give only select privileges to group or others. Typicaly
location -> database
mapset -> schema
UNIX user -> database user
UNIX group -> database group
Then user can grant select on schema to group and public.
Administrators should keep in sync database and UNIX users,
especially don't forget to remove database user if UNIX user
is removed.
If you revoke access to group or others using g.access,
you should also revoke privileges on related database schema.
I'am agree.
I'd like to know if is it possible to allow that more users work on the same
mapset?
The contemporary access can be avoid by a lock.
Thanks
- --
Leonardo Lami
lami@faunalia.it www.faunalia.it
Via Colombo 3 - 51010 Massa e Cozzile (PT), Italy Tel: (+39)349-1310164
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBpHVq92hCyP73w7ARAtd4AKCAsI0KIqPJdyMTycHcPmclfcCYdQCeOjd1
cXeNkqpeYizclo5hRyrc7lo=
=lz+S
-----END PGP SIGNATURE-----
Leonardo Lami wrote:
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and schema.
I think that there is problem to connect a vector with a table in a schema
with v.db.connect.
Cannot you simply use table=myschema.mytable ?
Radim
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alle 17:39, mercoledì 24 novembre 2004, hai scritto:
Leonardo Lami wrote:
> I think there is no problem if you remove v.database.
> I do not remember if you resolved the problem about v.db.connect and
> schema. I think that there is problem to connect a vector with a table in
> a schema with v.db.connect.
Cannot you simply use table=myschema.mytable ?
Radim
Hi Radim,
If I use this option with v.database or db.connect I have no problem but if I
use it with v.db.connect I have this ouutput message:
v.db.connect map=sir_clump driver=pg
database=host=192.168.0.10,dbname=faunalia,user=username,password=######
table=prova.anfibi key=cat field=1
ERROR: Table <prova.anfibi> does not exist in database
<host=192.168.0.10,dbname=faunalia,user=username,password=######>
Thanks
Ciao
Leo
- --
Leonardo Lami
lami@faunalia.it www.faunalia.it
Via Colombo 3 - 51010 Massa e Cozzile (PT), Italy Tel: (+39)349-1310164
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBpaCt92hCyP73w7ARAn+bAJ4g3RTP55CSwwYszr7mOPGX//1cTQCZAUF8
qUYnr/oVvR2ke9pAdIjTDEA=
=IvlZ
-----END PGP SIGNATURE-----
Leonardo Lami wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alle 17:39, mercoledì 24 novembre 2004, hai scritto:
Leonardo Lami wrote:
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and
schema. I think that there is problem to connect a vector with a table in
a schema with v.db.connect.
Cannot you simply use table=myschema.mytable ?
Radim
Hi Radim,
If I use this option with v.database or db.connect I have no problem but if I use it with v.db.connect I have this ouutput message:
v.db.connect map=sir_clump driver=pg database=host=192.168.0.10,dbname=faunalia,user=username,password=###### table=prova.anfibi key=cat field=1 ERROR: Table <prova.anfibi> does not exist in database
<host=192.168.0.10,dbname=faunalia,user=username,password=######>
For now, I just changed error to warning, so that it should give you error but it should connect the table.
I dont have postgres with schemas and I am not sure how some
functions should work, for example db_list_tables/db.tables
should return all tables in schema.table form?
Radim
I have removed v.database. Vector modules will use
default values set by db.connect.
db.tables returns schema.table if chemas are available.
You can use v.db.connect table=schema.table
Default schema can be set by db.connect.
WARNING: default schema is used by all db.* modules.
All this works with Postgres only.
Radim
Leonardo Lami wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is maybe too confusing to have separate default driver/database for
db.* and v.* modules. First I thought, that in some cases
it could be useful, but usually both groups of modules use the same
database. Driver/database options can be used if necessary (v.in.db).
What do you think, should we remove v.database and use db.connect
settings also for vectors?
Radim
-------------------------------------------------------
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and schema.
I think that there is problem to connect a vector with a table in a schema
with v.db.connect.
db.login was added to 5.7. It can be used to set user and password
for driver/database.
WARNING: password is stored as text in $HOME/.grasslogin5
User and password from database definition (db.connect,v.db.connect) is
no more used.
This change was necessary to allow work in groups. Now it is possible
to give only select privileges to group or others. Typicaly
location -> database
mapset -> schema
UNIX user -> database user
UNIX group -> database group
Then user can grant select on schema to group and public.
Administrators should keep in sync database and UNIX users,
especially don't forget to remove database user if UNIX user
is removed.
If you revoke access to group or others using g.access,
you should also revoke privileges on related database schema.
I'am agree.
I'd like to know if is it possible to allow that more users work on the same
mapset?
The contemporary access can be avoid by a lock.
Thanks
- -- Leonardo Lami
lami@faunalia.it www.faunalia.it
Via Colombo 3 - 51010 Massa e Cozzile (PT), Italy Tel: (+39)349-1310164
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBpHVq92hCyP73w7ARAtd4AKCAsI0KIqPJdyMTycHcPmclfcCYdQCeOjd1
cXeNkqpeYizclo5hRyrc7lo=
=lz+S
-----END PGP SIGNATURE-----