V2 - Automatic ID for Files Created Outside Org-Roam in Org-Roam Directory?

In v1, if I created a file with the #+TITLE: attribute within my org-roam directory, the org-roam DB would add it on its next scan/update. With V2, it seems that files created outside of org-roam-node-find or org-roam-capture don’t get IDs added automatically just because they live inside the org-roam directory, and therefore don’t get added to the database.

This is mostly not a big deal, but especially for anything I’m creating within emacs (for example, I added org-id-get-create to my org-journal template, and that seems to be working fine), but I have one or two use cases for creating files outside of emacs that I would like indexed by org-roam (for example, I have a little script to convert bibtex files into org files, and it’s convenient for those to be automatically indexed by org-roam).

I’m interested to know if this is expected/desired behavior, or if I might have a setting set incorrectly or the like.

1 Like

It’s a behaviour expected of the current implementation. Every node requires its ID by definition.

By design does not mean that implementation could be changed to auto add an ID to new files during db-sync, but that’s not the case now as far as I could see.

Just add an ID property in the script you mention. This ID should be recognised and cached by Org-roam next time you use org-roam-setup (db-sync).

One note is that this “custom-made” ID won’t be recognised by Org-ID. Its location would not be identified if you want to navigate to it from outside Org-roam.

If this is a problem, you’d need to update org-id location somehow. There are a plenty of other posts in this forum recently if you search (not at desk so can’t tell you the exact function names, etc.)

1 Like

Ah, thanks very much for the clarification. It should be pretty simple to add the text for a property drawer with an ID property along with something to generate a unique sequence (it’s written in python), and I think that at least for now, being recognized by Org outside of org-roam should not be much of an issue.

I twiddled with my python script to generate an id in the form of YYYYMMDDHHSS and insert it at the top of the file in a property drawer, and I can confirm that org-roam does indeed find it on its next sync, and that vanilla org does not know how to find it. For now, that’s a good enough solution for me, but if anyone else tries further/other automation, I’d be interested to see it.

1 Like

This should work.

Only lightly tested, and I have other means suited for me running in parallel so can’t confirm which did the job; but this solution is run, didn’t break anything, and should do the job.

I trust that you would test it before you commit using it :wink:

(defun my/org-id-update-location-at-org-roam-db-insert-file ()
  "Update `org-id-locations-file' and hash table.
It's meant to be used with `advice-add' :after
`org-roam-db-insert-file'.  We can assume that this function is
run wihtin a buffer visiting a file being inserted, as
insert-file is run within `org-roam-with-file' macro."
  (when-let ((id (org-entry-get 1 "id")))
    (org-id-add-location id (buffer-file-name))))

(advice-add #'org-roam-db-insert-file :after #'my/org-id-update-location-at-org-roam-db-insert-file)

EDIT: as you can see, it only works for file nodes.

1 Like

@jprussell
For future reference.

I have just upgraded to the latest commit 0a7d365, and observe that this behaviour is no longer the case; without the ID in the org-id-location-file cache, Org-roam does not recognise a file as a node.

The custom code above works (it adds the Org-ID location cache just before Org-roam tries to find the ID in a newly created file).

Ah, thanks very much for the heads up. I haven’t had a chance to try your code yet, but I’ll give it a shot tonight or tomorrow.

I was able to solve my other use case by adding a hook that calls org-id-get-create after a new file is created by org-journal (I currently use org-journal for daily entries, I haven’t checked out the native org-roam dailies yet).

If you are on Windows, you might like to wait a little bit longer to upgrade (issue I reported)