[GRASS5] Re: sqlite browser

[Hamish]

> Perhaps an environmental variable like SQL_BROWSER_PATH might be
> useful, given that the name (on my Mac at least) is full of spaces and
> has an embedded version number which will change with every update.
> Some kind of find that could return the name and path the the browser
> could automate this.

I don't think anything new or fancy is needed-

SQLITE_BROWSER="`which sqlitebrowser`"

should be enough. If a path with a space in it doesn't work, then it is
a variable quoting bug which should be systematically fixed. The browser
executable needs to be in the $PATH, that isn't a big ask.
Worst case make a symlink to it in /usr/local/bin or $GISBASE/bin/.


> I have several other randomly related thoughts.
> 
> 1. If we do use sqlite, we need a translation utility between dbf and
> sqlite. 

db.copy?

dbview -bt -d '|' | v.in.ascii
(replace dbview utility with db.select?)

The long wished for db.in.ascii module?


> 2. We might want to have an "sql" directory in each mapset, like we do
> for dbf.

Make that a "sqlite" dir, as "sql" is too generic to be meaningful.

> This would be the location for a default sqlite database for
> each mapset, containing tables for each vector file. The default
> database could simple carry the name of the mapset. This does not
> preclude the creation and use of other sqlite database in other
> locations, of course. 3. GRASS would need to be able to create an
> empty sqlite database automatically for each mapset, so that tables
> could be added as needed.

Maybe I don't understand sqlite (never used it); why doesn't each map
have its own DB file in the first place? Why does there have to be a
single all-of-mapset one? I can't imagine the overhead per DB is that
huge.


> The browser could actually live inside the GRASS directory structure
> (e.g., $GISBASE/bin or somewhere else meaningful) if included, as it's
> not all that big. In this case, it could be given a simple name like
> "sqlite_browser". This might make the test you propose easier. It
> could also be a link to the app in another location, but that might
> get more difficult.

I think it is best left as an external (and optional?) dependency. I
sure don't want to maintain the thing or keep it in sync. The more we
can outsource to gdal, proj4, etc., the better I think. We've got enough
to work on as it is. It's the packagers' jobs to take care of making
sure those things get installed too...

Also, I would suggest we not make any decision about changing the
default DB to sqlite until after GRASS 6.2 is released.



Hamish