• Sign In
  1. Messages

places where labkey hard codes filepaths in database?

LabKey Support Forum (Inactive)

View Message

view list print
places where labkey hard codes filepaths in database? Ben Bimber  2011-05-04 13:48
Status: Closed
 
we're about to migrate to a new server. the labkey file root is going to be copied, but the path to this location will be different. it appears labkey hard codes the paths to certain files in the db.

for example:

pipeline.statusfiles
exp.datas
maybe more

In theory I could create a sym link on the new server that replicates the old fileroot. the old filepaths would still work. I could also try to do a very careful find/replace directly in postgres on those 2 offending columns. i'd replace the old file root with the new one.

does anyone have experience with this? Are there any tables i missed besides those 2?

thanks for any help or advice.
 
 
jeckels responded:  2011-05-05 09:45
Hi Ben,

Here is a more complete list of tables that may store paths. Some, like those in the ms2 schema, likely don't have any data for your installation.

core.mappeddirectories (filesets)
exp.data (files referenced by assays, uploaded through the file management tool, etc)
exp.experimentrun (directory assay runs came from)
filecontent.fileroots (non-pipeline file roots)
genotyping.analyses (genotyping analyses)
genotyping.runs (genotyping runs)
ms1.files (path to MS1 mzXML files)
ms2.fractions (path to MS2 mzXML files)
ms2.runs (path to MS2 pepXML analysis results)
ms2.proteinprophetfiles (path to MS2 protXML analysis results)
pipeline.pipelineroots (pipeline roots, separate from file roots)
pipeline.statusfiles (log file for pipeline jobs)
prot.annotinserts (path to imported FASTA and SwissProt XML files)
prot.fastafiles (path to imported FASTA files)
prot.fastaloads (history of FASTA imports)
study.uploadlog (history of study loads)

It's possible that I missed a couple, but that should be pretty thorough.

I'll let Brian weigh in on tradeoffs between symlinks and database editing.

Thanks,
Josh
 
Ben Bimber responded:  2011-05-05 10:05
ok, thanks. my first instinct says that editing postgres fixes the problem completely, while the sym link works around it. it creates a need to maintain the odd sym link permanently, which only becomes more confusing next time we migrate or do anything similar. editing postgres does create more potential for error though.