[GRASS5] db.columns and v.info -c

[Michael Barton]

Although your point about duplicate functionality is correct, v.info -c is a
nice shorthand way to get the columns in the selected layer connected to a
vector. It is the way to easily get the show column button in the GIS
Manager.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Radim Blazek <radim.blazek at gmail.com>
> Date: Tue, 22 Nov 2005 19:18:46 +0100
> To: Maciek Sieczka <werchowyna at epf.pl>
> Cc: Markus Neteler <neteler at itc.it>, <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] db.columns and v.info -c
> 
> v.info -c must remain in 6.x.
> 
> You are right that v.db.columns would be better.
> 
> Radim
> 
> 
> On 11/22/05, Maciek Sieczka <werchowyna at epf.pl> wrote:
>> On wto, 2005-11-22 at 15:23 +0100, Markus Neteler wrote:
>>> On Tue, Nov 22, 2005 at 02:53:43PM +0100, Maciek Sieczka wrote:
>>>> On wto, 2005-11-22 at 10:31 +0100, Radim Blazek wrote:
>>>>> On 11/22/05, Maciek Sieczka <werchowyna at epf.pl> wrote:
>>>>>> Hi
>>>>>> 
>>>>>> I'm wondering if functionality of db.columns and v.info -c shouldn't be
>>>>>> merged into one command. Maybe extend db.columns to report types (other
>>>>>> info? say: number of records per column, check if null records
>>>>>> present/absent, number of null records?) and remove "-c" from v.info?
>>>>>> 
>>>>>> Maciek
>>>>> 
>>>>> How do you want to merge v. and db. commands?
>>>> 
>>>> Isn't v.info -c an example?
>>> 
>>> No: it shows the columns of a table *connected* to a
>>> vector map.
>> 
>> I know.
>> 
>>> But you can have many tables not connected to vector maps
>>> in your database. The v.* commands do not see them, but
>>> the db.* commands do see them.
>>> 
>>>>> One works on vector and the other on table.
>>>> v.info -c works on a table
>>> 
>>> Yes, but only on a table connected to a certain
>>> vector map.
>> 
>> 
>> 
>> I'm affraid I wasn't explicit enough in my fisrt post. Other words then.
>> 
>> Is it necessary to maintain "v.info -c" when db.columns, in conjnction
>> with "v.db.connect -p", provides the same functionality?
>> 
>> In order to know what table my_vector is connected to I do "v.db.connect
>> -p my_vector", then db.columns on the resulting table name to learn
>> about it's columns (using v.db.connect for learning the name of
>> connected table is pretty intuitive, as it is used also for connecting
>> and distonecing tables, should be no problems here for newbies).
>> 
>> Currently both "v.info -c" and db.columns print the column name -
>> doubled functionality. Only v.info -c prints the column type tough.
>> Instead of maintaing both commands, wouldn't it be better to implement
>> printing the column type in db.columns (or make it print even more
>> information besides coulmn name and type) and get rid of "-c" in v.info?
>> 
>> I'm rising this because:
>> 1. I believe that a user will first seek for a command which can
>> describe a table I) among the db.* commands II) v.db.* III) v.* (v.info
>> would be the last reasonable place to look for it if I were a newbie,
>> let's make it easier).
>> 
>> 2. I remember one of the goals in Grass>=5.7 was to get rid of doubled
>> functionality.
>> 
>> Maciek
>> 
>> 
>> --------------------
>> W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko
>> najlepsze z nich!
>> http://katalog.epf.pl/
>> 
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
>> 
>