[GRASS-dev] [GRASS GIS] #3149: Adding database information to v.info metadata output

[GRASS GIS]

#3149: Adding database information to v.info metadata output
--------------------------+----------------------------------
  Reporter:  huhabla      |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.2.0
 Component:  Default      |    Version:  svn-releasebranch72
Resolution:               |   Keywords:  vector, info, v.info
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+----------------------------------

Comment (by mlennert):

 Replying to [comment:5 huhabla]:
 > Replying to [comment:4 mlennert]:
 > > Replying to [comment:3 huhabla]:
 > >
 > > >The output of v.db.connect -g is not well
 > > >designed for parsing, neither for bash
 > > >nor for the python-grass-script library.
 > >
 > > Then let us improve that :-)
 >
 > I guess there was a specific reason behind the implementation of the
 "-g" flag in v.db.connect in the way it is. I fear to break existing
 functionality when modifying v.db.connect "-g" flag output.
 > Since we do not have enough module tests, it would be hard to figure out
 what will break in existing modules, in examples and documented work flows
 and even more harder to figure out if extensions will break.

 One option could be to create another flag (-f?) which would "unFlatten"
 the output of -f and provide a key=value output.

 >
 > >
 > > Just to be clear: this is not a -1 to your idea. I just want to make
 sure we think about it. In general, I'm wary of introducing the same
 functionality in two different modules. IMHO, it creates the risk of
 feature bloat and of confusion for the users.
 >
 > IMHO the database connection is vector map metadata that should be
 available within v.info, so the user does not have to search for another
 module to get this information. The default settings of vector layer
 database management usually does not require the user to use v.db.connect,
 hence its capabilities is mostly unknown to the user.


 I understand the concern, but remain afraid that such logic leads to
 feature bloat of modules as many things would be nice to have in one
 single module. But then again, I'm probably just biased as I started using
 GRASS before the advent of v.db.*...

 >
 > I think the less invasive solution is to modify v.info, especially since
 i have already implemented 6 tests to verify the functionality. ;)


 As much as I understand that already done work would be frustrating to
 abandon, I don't think that this should enter into account in this
 discussion...

 >
 > BTW, v.info is an integral part of the gunittest validation approach,
 hence the more metadata information about a vector map is available via
 v.info, the easier it is to implement tests.

 Because otherwise you have to call two modules ? Again, I would not want
 test creation logic to be what decides about module functionality.

 But I'll shut up now and let you go on with your work. As others don't
 seem to share my worries, this is probably me just rambling on a hangover
 Sunday... ;-)

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3149#comment:6>
GRASS GIS <https://grass.osgeo.org>