Re: determine client os

On 06/14/2011 05:54 PM, Sim Zacks wrote:

> I have a system settings table which defines mount points.
> I have a directories table which defines the relative path (from the
> mount point) for each type of document.

OK, so your clients already have all the information they need to
assemble the paths themselves. You don't need the views. Hand clients
the relative paths, and they can use the information from the system
settings table to assemble the full path trivially.

Advantages of doing it this way include:

- The server doesn't need to know the client OS

- The client can read the mount point or drive letter setting
from the database *once* on startup and cache it. You won't send
it each time with each file path, saving network I/O. It knows its
own OS, so it knows which settings to read.

- Queries are cheaper and simpler because there's no need for string
assembly and views that use system settings tables.

> In the table where the file reference is stored it shows
> #doctype#filename.ext.
> I have a view which puts together the full windows and linux paths for
> each document type. In the query that retrieves the file reference it
> does a replace for the specified doctype.

So you store different document types in different mount points / drive
letters? Is that why you're doing this substitution?

If so: again, the client can do this substitution. It knows its own OS
and can read the settings table once.

(If you expect settings to change a lot you can always have clients
LISTEN for NOTIFY events on change).

> I don't see any practical way of being so flexible that the user can
> change drive letters and/or mount points and still expect file paths to
> work.

If you want all-server-side configuration, then yep, you're pretty much
stuck with fixed paths.

Many packages I've used have a client-side config file that can be used
to control path and database access settings, so clients with special
needs can change paths etc. If all clients are configured the same, it's
typical to put the config file on a shared volume via a UNC path. The
app is invoked with a shortcut / wrapper script / environment variable /
registry setting that specifies the config file path.

You presumably have some minimal client configuration mechanism already
so the client can discover which server to talk to. Same principle.

--
Craig Ringer