Split out data and code?

[Nancy Palmquist]

Mark,

The logic that allowed filepro to be split across multiple disks is 
still part of filepro and can be used like this.

You need the following:

/appl/filepro
/var/appl/filepro

PFDSK=/appl:/var/appl  ' this represents the order it searches. First 
location should be programming, second would be data.

On /appl/filepro/filename
You will need map, prc. etc.  NO KEY, NO DATA, NO INDEXES

On /var/appl/filepro/filename

You will put the key,data,index

I use this logic to share one key, data, index between 2 servers and it 
works fine.  In your case, setting up different PFDSK so a different 
/var/appl/filepro is specified for each customer should work.

WARNING: If you ever rebuild an index from scratch, it will put it on 
the /appl/filepro side not the secondary location.  So if you need to 
create indexes, always make the filename where you want it first then 
build it, I think I recall this would properly locate the index.



On 11/21/2019 8:33 AM, Fairlight via Filepro-list wrote:
> I have a particular need for a business, and need to know if filePro
> supports a particular topography natively.
>
> This is for filePro 5.0.14 on Linux, and it -won't- be upgraded,
> guaranteed, even if the feature is available only in later versions.
> Please constrain answers to relevancy for that version.
>
> By default, filePro co-mingles its code and data in the same directory for
> each file.  Maps, key and data segments, indexes, screens, output
> definitions, selection sets, processing tables and tokenised versions of
> them, etc., all live in the same place.
>
> What I need to achieve is the ability to have:
>
> * One directory (preferably the same current location of $PFDIR) retaining
> the data (key/data, indexes, lockfiles).
>
> * A -separate- directory taking up the role of housing the code (prc/tok,
> browses, maps, selection sets, outputs, screens, etc.).
>
> The goal is to split these off so that gigabytes and gigabytes of
> customer data can remain where they are, but the application itself can
> be containerised with docker.  This is to facilitate distribution and
> implementation of an application on a version-specific level (v1, v2 ..
> v47, etc.), and secondarily for resource protection.  Drop in a whole new
> version of an application spanning hundreds of filePro files, and run your
> Apache-driven product.  If there's a problem, switch containers back to the
> last version.  Instant rollback.  There are huge benefits in multiple
> areas, from ease of distribution and deployment, to rollback ability.
>
> So far, my attempts to make this happen have hit a brick wall in that the
> container version of the directory is subject to occlusion by the bind
> mount with the data files.  You only see the data files.  If you exclude
> the bind mount, you can see the code, but you have no data.  This is a
> problem.
>
> I've considered symlinks from the data directory into the location where we
> might move code to in the container structure, but that whole thing doesn't
> play nicely with git, which really doesn't like symlinks as much as you'd
> hope.  It is not an exaggeration to say that I would need to generate
> hundreds of thousands of symlinks to start, across all filePro files, and
> then implement and maintain the practise of adding new ones any time
> something new is instantiated.  That seems unwieldly, and I don't want to
> impose that upon the developers if I don't have to.
>
> Copying the data into the container is going to be too slow at startup,
> given that it can be a few hundred gigs of data...per customer.  That's not
> going to happen.  So it's either split this apart and get both sets of
> files under the same directory -somehow-, or find a way to use two separate
> directories.
>
> I'm open to viable suggestions.
>
> Thanks!
>
> mark->

-- 
Nancy Palmquist         MOS & filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20191121/d9136740/attachment.html>