If I try to remove the column cat by hand ( as suggested in a post in the ml),
it goes fine:
GRASS 6.4.svn (wrme):~ > db.dropcol -f aste_geo_bak colum=cat
Forcing ...
WARNING: Deleting <cat> column which may be needed to keep table connected
to a vector map
If I try to remove the column cat by hand ( as suggested in a post in the ml),
it goes fine:
GRASS 6.4.svn (wrme):~ > db.dropcol -f aste_geo_bak colum=cat
Forcing ...
WARNING: Deleting <cat> column which may be needed to keep table connected
to a vector map
On Fri, 30 May 2008 04:17:51 -0700 (PDT)
doktoreas <thedoktor78@gmail.com> wrote:
Markus Neteler OSGeo wrote:
>
> Luca,
>
> can you replicate this with Spearfish or the NC data
set?
> Then we could easier test things...
>
> Markus
>
>
Hi Markus,
those are the steps to replicate the problem with NC
dataset ( all is done
in a new mapset called sqlite):
v.db.join never worked for me when the columns had the same
name. I rename one of the columns and there is no problem.
I was also wondering if there is a reason for that or if it
is a bug.
in your case rename one of the "cat" columns to lets say
"cat_x" and do:
v.db.join map=urbanarea column=cat otable=urban_point
ocolumn=cat_x
On Fri, 2008-05-30 at 06:32 -0700, doktoreas wrote:
Markus Neteler OSGeo wrote:
>
> On Fri, May 30, 2008 at 1:17 PM, doktoreas <thedoktor78@gmail.com> wrote:
>> Markus Neteler OSGeo wrote:
>>>
>>> Luca,
>>>
>>> can you replicate this with Spearfish or the NC data set?
>>> Then we could easier test things...
>>>
>>> Markus
>>>
>>>
>>
>> Hi Markus,
>>
>> those are the steps to replicate the problem with NC dataset ( all is
>> done
>> in a new mapset called sqlite):
>>
>> db.connect driver=sqlite
>> database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
>> g.copy vect=urbanarea@PERMANENT,urbanarea
>> v.extract -t input=urbanarea output=urban_point type=point,centroid
>> v.db.addtable urban_point
>>
>> v.db.join map=urbanarea column=cat otable=urban_point ocolumn=cat
>> ..
>> DBMI-SQLite driver error:
>> Error in sqlite3_prepare():
>> duplicate column name: cat
>>
>> ERROR: Error while executing: 'ALTER TABLE urban_point ADD COLUMN cat
>> INTEGER
>> '
>> ERROR: Cannot continue (problem adding column).
>> ERROR: Cannot continue.
>>
>> Thanks for your help
>
> Like this it was easy to replicated.
> (Hopefully) fixed in 6.4.develbranch and 7.trunk.
>
> You can grab the fixed script also here:
> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.join/v.db.join
> (download at page bottom)
>
Does this mean that the failure of join when using columns with the same
name was a bug?
>>> can you replicate this with Spearfish or the NC data set?
>>> Then we could easier test things...
>>>
>>> Markus
>>>
>>>
>> Hi Markus,
>>
>> those are the steps to replicate the problem with NC dataset ( all is done
>> in a new mapset called sqlite):
>>
>> db.connect driver=sqlite
>> database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
>> g.copy vect=urbanarea@PERMANENT,urbanarea
>> v.extract -t input=urbanarea output=urban_point type=point,centroid
>> v.db.addtable urban_point
>>
>> v.db.join map=urbanarea column=cat otable=urban_point ocolumn=cat
>> ..
>> DBMI-SQLite driver error:
>> Error in sqlite3_prepare():
>> duplicate column name: cat
>>
>> ERROR: Error while executing: 'ALTER TABLE urban_point ADD COLUMN cat
>> INTEGER
>> '
>> ERROR: Cannot continue (problem adding column).
>> ERROR: Cannot continue.
>>
>> Thanks for your help
>
> Like this it was easy to replicated.
> (Hopefully) fixed in 6.4.develbranch and 7.trunk.
Do I understand correctly that the patch ignores the column if the name
already exists ? Wouldn't it be more "user-friendly" to rename it ?
I don't know about "user-friendly", but it would be safer to just
abort with an error if the column already exists.
If you're going to replace the contents of an existing column, you
should only do so if --overwrite is given.
>> > (Hopefully) fixed in 6.4.develbranch and 7.trunk.
>>
>> Do I understand correctly that the patch ignores the column if the name
>> already exists ? Wouldn't it be more "user-friendly" to rename it ?
>
> I don't know about "user-friendly", but it would be safer to just
> abort with an error if the column already exists.
>
> If you're going to replace the contents of an existing column, you
> should only do so if --overwrite is given.
Sounds reasonable.
It would be good if someone adds both error abort and --overwrite
flag in that script.
AIUI, you already have the error abort for free, due to v.db.addcol
failing.
Handling --overwrite would be nice, but in the meantime the main thing
is not to try to circumvent the error by unconditionally deleting the
column. So, I have reverted your recent change.
Like this it was easy to replicated.
(Hopefully) fixed in 6.4.develbranch and 7.trunk.
Do I understand correctly that the patch ignores the column if the name already exists ? Wouldn't it be more "user-friendly" to rename it ?
I don't know about "user-friendly", but it would be safer to just
abort with an error if the column already exists.
If you're going to replace the contents of an existing column, you
should only do so if --overwrite is given.
I'm not speaking about replacing any content. I'm proposing that if you have a column cat in each table, then the second is renamed to something like cat2, so that you can have both in the resulting table.
>>>> those are the steps to replicate the problem with NC dataset ( all is done
>>>> in a new mapset called sqlite):
>>>>
>>>> db.connect driver=sqlite
>>>> database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
>>>> g.copy vect=urbanarea@PERMANENT,urbanarea
>>>> v.extract -t input=urbanarea output=urban_point type=point,centroid
>>>> v.db.addtable urban_point
>>>>
>>>> v.db.join map=urbanarea column=cat otable=urban_point ocolumn=cat
>>>> ..
>>>> DBMI-SQLite driver error:
>>>> Error in sqlite3_prepare():
>>>> duplicate column name: cat
>>>>
>>>> ERROR: Error while executing: 'ALTER TABLE urban_point ADD COLUMN cat
>>>> INTEGER
>>>> '
>>>> ERROR: Cannot continue (problem adding column).
>>>> ERROR: Cannot continue.
>>>>
>>> Like this it was easy to replicated.
>>> (Hopefully) fixed in 6.4.develbranch and 7.trunk.
>> Do I understand correctly that the patch ignores the column if the name
>> already exists ? Wouldn't it be more "user-friendly" to rename it ?
>
> I don't know about "user-friendly", but it would be safer to just
> abort with an error if the column already exists.
>
> If you're going to replace the contents of an existing column, you
> should only do so if --overwrite is given.
I'm not speaking about replacing any content. I'm proposing that if you
have a column cat in each table, then the second is renamed to something
like cat2, so that you can have both in the resulting table.
I think that it would be better to just force the user to pick another
name for the ocolumn= option. That way, the user will know what the
column is named.
Also, in a script, silently renaming the output column may result in
the script silently producing bogus results.
More generally, if there's a problem, you tell the user that there's a
problem, not pretend that there isn't a problem.
AFAICT, the only real flaw with the original script is that the
"duplicate column name: cat" error wasn't especially visible.
Other than that, everything happened as it should have done.
> I'm not speaking about replacing any content.
> I'm proposing that if you have a column cat in each
> table, then the second is renamed to something
> like cat2, so that you can have both in the resulting
> table.
Glynn:
I think that it would be better to just force the user to
pick another name for the ocolumn= option. That way, the user
will know what the column is named.
Also, in a script, silently renaming the output column may
result in the script silently producing bogus results.
