Understood, but if it were reversible, it would eliminate the necessity of a
lookup table as an intermediary.
Bob S
> On Sep 23, 2020, at 11:26 AM, Richard Gaskin via use-livecode
> <use-livecode@lists.runrev.com> wrote:
>
> If I understand her problem correctly, file identification need only be in
> one direction.
>
> As far as I can tell from the description, everything that needs to determine
> which file to access does so by using a string from which the hashed file
> name can be derived.
>
> That she already has a munger to derive the file name seems to reinforce that.
>
> My only suggestion was to change how the existing munger works to satisfy the
> two problem areas identified: that names not be too long, and that any munger
> not remove so many characters as to make the file name non-unique or empty.
>
> In some respects the benefits of a hash in this case are similar to using a
> UUID. But UUID is arbitrary and therefore requires establishing and
> maintaining a lookup table. In contrast, a hash is directly derivable from
> the file name, providing the same benefit as UUID for this case but without
> the need for a lookup table.
>
> Like the old saying goes, "There are two hard problems in computer science:
> cache invalidation, and naming things".
>
> Lookup tables are effectively a form of cache, a secondary replication of
> data, very useful at times but best avoided unless absolutely necessary.
>
>
> - Richard Gaskin
> Fourth World Systems
>
>
>
> Bob Sneidar bobsneidar at iotecdigital.com
>
> > How do you get back to the filename?
>
> > On Sep 23, 2020, at 8:03 AM, Richard Gaskin wrote:
> >
> >> One workaround for their storage name limitations I've seen used
> >> elsewhere is hash-based names, giving you a string that is plain
> >> ASCII, of a fixed and usable length, and is derived from the file
> >> name so systems don't need to maintain a lookup table to find the
> >> file based on a given string.
> >>
> >> This will give you a 40-char string in plain ol' ASCII unique to the
> >> input:
> >>
> >> function CleanHash s
> >> get binaryDecode("h*", sha1Digest(s), tHash)
> >> return tHash
> >> end CleanHash
> >>
> >> e.g.:
> >>
> >> get CleanHash("MyFile.txt")
> >>
> >> ...returns:
> >>
> >> d9275b8f757ce47c240d276c1e1192dae8585eba
> >>
> >>> ...When the user selects a name from a list, the selection is munged
> >>> to match the server name and the download URL is obtained from the
> >>> cron job's lookup file.
> >>>
> >>> We don't have a field in the database for a file name.
> >>
> >> Since a hash is derived from the file name, you don't need to
> >> maintain a lookup table as you would with an arbitrary string like
> >> UUID.
> >
> >> If I understand your problem correctly, that file identification need
> >> only be in one direction, just add the hash as part of your existing
> >> munge and you're pretty much done.
> >>
> >> --
> >> Richard Gaskin
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
