Hello,
As I mentioned in a separate mail, I agree with Daniel that using external
(point-and-click) tools might not be the best way for GRASS attribute
management.
So, here are two small modules which interface db.execute for specific tasks,
respectively adding a column and updating a column value. Others might follow
according to need.
Any feedback welcome.
Moritz
v.db.addcolumn (1.8 KB)
Moritz Lennert wrote:
Hello,
As I mentioned in a separate mail, I agree with Daniel that using external
(point-and-click) tools might not be the best way for GRASS attribute
management.So, here are two small modules which interface db.execute for specific tasks,
respectively adding a column and updating a column value. Others might follow
according to need.Any feedback welcome.
Moritz
Good, I'll use both.
v.db.addcolumn
--------------
I think that v.db.addcolumn should support the possibility to add more columns in one step. It is however dangerous (name - type order for more columns) to have column names and typse in 2 separated options. I suggest one option columns in format
columns="name1 type1[, name2 type2, ...]"
the same option is already used in v.in.ascii.
Do you think that it is too difficult for users to write
columns="newcol integer"
instead of
colname=newcol coltype=integer
???
v.db.update
-----------
If possible, we should use the same names of options which are already used in existing modules.
AFAIK in existing modules is used 'column', not 'colname'.
Also 'sqlwhere' should be replaced by simple 'where' which is used in many other modules.
Radim
On Wed, May 25, 2005 11:49, Radim Blazek said:
Moritz Lennert wrote:
Hello,
As I mentioned in a separate mail, I agree with Daniel that using external
(point-and-click) tools might not be the best way for GRASS attribute
management.
So, here are two small modules which interface db.execute for specific tasks,
respectively adding a column and updating a column value. Others might follow
according to need.
Any feedback welcome.
MoritzGood, I'll use both.
v.db.addcolumn
--------------I think that v.db.addcolumn should support the possibility to add more
columns in one step. It is however dangerous (name - type order for more
columns) to have column names and typse in 2 separated options. I suggest
one option columns in format
columns="name1 type1[, name2 type2, ...]"
the same option is already used in v.in.ascii.
Do you think that it is too difficult for users to write
columns="newcol integer"
instead of
colname=newcol coltype=integer
No I guess it is not too difficult, although I have actually been thinking in
a different, even simpler direction where the user wouldn't enter the type,
but chose it from a drop-down menu. Is this realistic or are the available
types different for every database backend ?
This said, if I implement your suggestion: can this be done in one alter table
command (and if yes could you show me since I can't seem to find out how), or
would this be one alter command for each new column (not difficult to code
either) ?
v.db.update
-----------If possible, we should use the same names of options which are already used
in existing modules.
AFAIK in existing modules is used 'column', not 'colname'.
Also 'sqlwhere' should be replaced by simple 'where' which is used in many
other modules.
I'll correct that.
Thanks !
Moritz
Moritz Lennert wrote:
On Wed, May 25, 2005 11:49, Radim Blazek said:
Moritz Lennert wrote:
Hello,
As I mentioned in a separate mail, I agree with Daniel that using external(point-and-click) tools might not be the best way for GRASS attribute
management.So, here are two small modules which interface db.execute for specific tasks,
respectively adding a column and updating a column value. Others might follow
according to need.
Any feedback welcome.
MoritzGood, I'll use both.
v.db.addcolumn
--------------I think that v.db.addcolumn should support the possibility to add more
columns in one step. It is however dangerous (name - type order for more
columns) to have column names and typse in 2 separated options. I suggest
one option columns in formatcolumns="name1 type1[, name2 type2, ...]"
the same option is already used in v.in.ascii.
Do you think that it is too difficult for users to write
columns="newcol integer"
instead of
colname=newcol coltype=integer
No I guess it is not too difficult, although I have actually been thinking in
a different, even simpler direction where the user wouldn't enter the type,
but chose it from a drop-down menu. Is this realistic or are the available
types different for every database backend ?
Yes, column types cannot be predefined because depends on database.
This said, if I implement your suggestion: can this be done in one alter table
command (and if yes could you show me since I can't seem to find out how), or
would this be one alter command for each new column (not difficult to code
either) ?
You have to parse imput and use more commands.
Radim