Re: determine client os - Mailing list pgsql-general

On 06/14/2011 10:29 AM, Craig Ringer wrote:

> On 14/06/11 14:35, Sim Zacks wrote:
>
>> It is much simpler then that. My data includes file references.
>> One table has the filename with a path placeholder and another table
>> contains the windows and linux versions of the full path. This is for an
>> intranet and we _always_ have the same drive letters (windows) and mount
>> paths (linux) for every client. When the client requests data that
>> includes a file reference, I want to send the relevant path.
> Just send the client the relative path component under the mount point /
> drive letter / whatever.
>
> If your storage is mapped to "/net/myapp/files" on your Linux/unix
> boxes, and "Z:\" on your Windows boxes, both these paths:
>
> /mnt/myapp/files/project1/file.bin
> Z:/project1/file.bin
>
> ... share the same relative path component "project1/file.bin". Just
> send that to the client and let it concatenate the fixed prefix path to
> the storage root. That way you aren't hard-coding drive letters and
> mount points, and you only have to store paths once in the database. The
> client knows what OS it is and it knows where the storage root is
> mounted/mapped; the database server doesn't need to know.
>
> Yes, I know I showed the windows path with forward slash separators. As
> far as I can tell, these days doesn't care about this - it's quite happy
> with forward slash separators. If you find it to be a problem you can
> always have your Windows clients flip the separators.
>
> Trust me, your users and anyone else working on the codebase later will
> hate you if you try to do it the way you're proposing. I speak from
> horrid experience working with a (closed-source, legacy) product that
> did just what you want to do. It's a bad idea. If nothing else, what
> will you do when you have to add a phone client that has to access the
> files over HTTP or WebDAV requests? It's easy if you store just the
> relative path, but a nightmare if your DB must store full paths. Not to
> mention all the wasted storage space your proposed method requires.
>
> --
> Craig Ringer
My structure is rather flexible and not bloated and we obviously don't
store the entire file path per record in the database.
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.
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.

If in the future we decide to add a web functionality, it can easily
work with the same setup, using the protocol and base as the "mount
point" and the path will still work correctly. Then the client just has
to know how to access the link type.

If I have a problem of users changing drive letters and/or mount points
then I'll have a more serious issue. For the plannable future, we have a
set of network standards, such as drive letter/mount path  for corporate
file server. We have had instances where a user changed the network
point complained that something didn't work. We are very inflexible
regarding that point. The answer was that if he changes the network
paths then the system will not work.

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. UNCs are nice, but only work for Windows and in my experience
(from a few years back) are much slower then mapped drives. Then we
would need to be configured per machine instead of on the server and
then if the user changes something on the machine again it will have to
be reconfigured. Of all the options, I like the "This is the drive
letter and mount paths that must be used if you want this application to
work."