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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
