Split out data and code?

[Fairlight]

Nancy,

No matter which order I use for PFDSK, rclerk is giving me:

"No screens found for 'REDACTED'."

Ideas?

m->


On Thu, Nov 21, 2019 at 01:37:02PM -0500, Nancy Palmquist via Filepro-list thus spoke:
> 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>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Fairlight Consulting
http://www.fairlite.com
fairlite at fairlite.com
(502) 509-3840