Hi Bridger,
I want to be able to load up individual (if largish) XML documents and check
that their id values (which are complex, and which downstream applications rely
on to work) are correct. Since the id values accumulate (your id starts with
the id of your closest ancestor with an id), creating them is much easier if I
can create all the individual, per-element components and then put them
together. All of that works with generate-id() because I can put one set of id
values in a map and do everything in the map.
It's once I want to relate the id back to the document ("this generated value
goes with this id attribute node") that I'm having trouble. I don't want to use
path(); it'd work, but it's not an efficient approach. (Or at least I don't
understand it as efficient.)
I find myself thinking that your "update the document with an attribute
containing a generated id value and use that" approach might be the best; I'm
going to try job:execute and db:node-id() first, though, because I'll learn
something. (And I'll look at store in the hopes that it's easier than creating
single document dbs with job:execute.)
Thank you!
Graydon
On Mon, Feb 9, 2026, at 11:16, Bridger Dyson-Smith wrote:
> Hi Graydon -
>
> I'm curious to hear other thoughts on this, I recall a struggle with
> something similar (wanting persistent access to node identifiers), and
> I wound up with a kludge that leveraged `db:node-pre()` and
> `db:get-id()`. I *think* trying to make in-database identifiers
> persistent would be circular, ie you write the file to the database,
> generate the node-id/node-pre values, but exposing those values in the
> document would change the document, and.... I'm not sure if I'm
> thinking about it clearly or not. Also, now that I think about it, I'm
> not entirely sure if the db:node-id/db:get-id is persistent - the
> db:node-pre/db:get-pre will change if documents are updated/deleted.
>
> What about a pre-processing step that ran an identity transform that
> added a `generate-id()`'d identifier to your chosen elements, then
> adding the document to your db?
>
> I don't think I answered your question, but I'm curious to learn more.
> Best,
> Bridger
>
> PS after adding a document to the database, you could run a process
> that updated a map in the `store` main memory using the
> db:node-id/db:get-id functions, then you could refer to that?
>
> PPS Excuse any misunderstanding of the problem. I'm insufficiently
> caffeinated today.
>
> On Mon, Feb 9, 2026 at 10:48 AM Graydon Saunders via BaseX-Talk
> <[email protected]> wrote:
> >
> > Hi!
> >
> > I'm loading a document with doc() and doing a bunch of stuff to regenerate
> > id attribute values; I'm using generated ids (from generate-id()) as map
> > keys so I can generate the local, this-element id component and then put
> > them all together from the list of ancestor ids. That works.
> >
> > What doesn't work is trying to use those ids to identify the element which
> > should get this newly constructed id value; calling generate-id() again on
> > the same document doesn't give the same answers. (which is to be expected,
> > at least as I understand how generate-id() is defined.)
> >
> > I have this vague memory that there's a BaseX function that will produce a
> > stable id, but can't remember what it is called. (Or if it will work when I
> > get the document with doc().)
> >
> > Is there such a thing, and if so, what module should I be looking in?
> >
> > Thanks!
> > Graydon
>
