Re: org-id-locations as a large-scale database store?

[Laurence von Bottorff]

Any docs on what org-id-locations is about, who/what uses it?

On Tue, Mar 12, 2024 at 1:44 PM Ihor Radchenko  wrote:

> yeti  writes:
>
> >> Does org-brain have anything to do with org-id-locations?
> >
> > I think so...
> >
> > E.g. org-brain.el 788-794:
> >
> > ---8<---
> > (defun org-brain-entry-from-id (id)
> >   "Get entry from ID."
> >   (unless org-id-locations (org-id-locations-load))
> >   (when-let ((path (gethash id org-id-locations)))
> > (list (org-brain-path-entry-name path)
> >   (org-brain-headline-at (org-id-find id t))
> >   id)))
>
> That's redundant. Calling `org-id-find' would suffice (org-id-find
> internally arranges org-id-locations to be updated).
>
> In any case, loading and searching id locations scales well for
> thousands of entries - I currently have 60+k entries there without
> issues.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com

org-id-locations as a large-scale database store?

[Laurence von Bottorff]

I've been using a package called org-brain that is using, I'm all but
certain, the org-id-locations file as its database to store graph-like
relationships between org files and org headings. org-brain is a sort of
graph database which adds a PROPERTIES drawer with just the ID field with a
UUID to an org file, as well as to the org headings in each file. So I
opened this 127k file residing in my .emacs.d directory and apparently
whatever is in my org directory and has a PROPERTIES drawer with ID field
winds up in .org-id-locations represented as plists in one big list, one
for each file that has one or more drawers. But you knowledgeable people
here know all this already. However, it surprised me since such a format as
this

(...("~/Dropbox/org/orgb_fassungen/FassungenDesc.org"
"1ba78dfc-d6c3-46c5-827d-37db94fa9053"
"6809202d-9a4c-4ed0-87fb-798676f448fe"
"f2149157-6ba1-4e24-81c3-4e070fcc5de8"
"5b7c2d9a-2df8-450a-a0c8-9d3b8e703044"
"f3031b9f-3708-493d-9546-f489835c9f17")
("~/Dropbox/org/orgb_fassungen/Fassungen.org"
"e9b683af-90b1-4ece-9afd-18dc28a9fab2")...)

where, e.g., inside the file FassungenDesc.org there are many org headings,
each with a PROPERTIES/ID drawer -- and they're all associated
to FassungenDesc.org with that simple list. So I'm asking if this is a good
design for a really big graph database? I'd like to start using org files
and their containing headings as vertices. But I'm guessing this is not
really all that scalable, not really intended for such a big thing. I saw
another emacs graph database (https://github.com/toshism/netz) that uses
h.el hash to store graph vertices and edges. So again, is this org-brain
approach DOA for anything big? I plan on having potentially hundreds of org
files with very many heading entries each (over a thousand perhaps per
file) representing vertices. What would be a better way of databasing org
files and headings? The PROPERTIES/ID drawer idea is fine, but not throwing
it all in .org-id-locations, right?

Ancillary: If I move or delete .org-id-locations, Emacs will rebuild it,
right? What is the idea behind having such a file structured this way --
other than a simple database? What else uses it?

-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com

ob-haskell and changing executables?

[Laurence von Bottorff]

I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
the stack tools behind, as advised these days. ghcup puts executables for
Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
directory. Next, to stop using the stack tools that have executables in
/usr/bin/ you must change your PATH to go to ~/.ghcup/bin first. But when I
try a Babel code block, ob-haskell seems to have the /usr/bin versions
hardwired somewhere and calls up the old ghci REPL. Searching through Emacs
Customize Haskell was confusing and my init only had one relevant entry
anyway, which didn't help when I changed it.

In the /usr/bin directory the Haskell execs are linked to just one specific
version. In my case /usr/bin contained symbolic links ghc -> ghc-9.0.2 and
ghci -> ghci-9.0.2. This is not great, since Haskell in the wild is
project-based, i.e., differing versions of the ghc compiler can be used in
different projects, as well as wildly diverging libraries and packages per
project. Obviously Babel can't easily take advantage of this, but Haskell
does allow "system-wide" library installs.

My solution was to simply delete the symlinks in /usr/bin and create new
ones to the ghcup tools, e.g., ghc -> ~/.ghcup/bin/ghc etc. So now it works
properly and calls up the new ghcup ghci when I do a Haskell Babel block,
but this is a kludge. No elisp master, I can't find where this /usr/bin
address is hardwired. If you've gotten this far you probably know more
about the Haskell Babel situation than you ever wanted to, but maybe you
can sniff out where this hardwire is happening.

-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com