Split out data and code?

[Richard Kreiss]

Mark, I had done this many years AND FORGET HOWE I did it.  The issue I ran
into, as I recall, was with indexes and rebuilding them.

This was on a windows system and not *nix.

I could try and remember what I had done as the indexes were in a different
location then the rest of the filePro files.  I did this to insure space
when storage was limited and expensive.  I(t made sense then but in today's
workd oif ever expanding storage capacity with lower and lower costs, this
became unnecessary.  

If I remember how I configured the  startup file, I will send it to you.

Richard Kreiss



> -----Original Message-----
> From: Filepro-list
<filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com>
> On Behalf Of Fairlight via Filepro-list
> Sent: Thursday, November 21, 2019 8:34 AM
> To: filepro-list at lists.celestial.com
> Subject: Split out data and code?
> 
> 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->
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list