From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id wJFuCF7i72UgOAAAe85BDQ:P1 (envelope-from ) for ; Tue, 12 Mar 2024 06:04:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id wJFuCF7i72UgOAAAe85BDQ (envelope-from ) for ; Tue, 12 Mar 2024 06:04:30 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="E/i5dZO1"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710219870; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Z2yuVyOCwH8aqZF14lJ2DpxuZzgQoUVn0XApQbmls64=; b=uEdEdyBeAWNst4w0gjdhzn/5viHZ0bOWs/z/S9Dqi03b/rlZmGyd/r10ICmgRedfnEEDt8 8Yp1ec148Nkd3dx/o0+BaRjYTCBM5woddA/Lh/iD+y6Q41Qjj3ma0Zcs04Ve5aylLJwHjH prPjWI1z576gpCb4dB37Ro0dLpCZimJ2pajQkoo6F4hOKLFfUMdWNt55XtU/GcW0sBPiNz RJ2ISbPYxvKNUgBs0Zkmeyz/qbkkBx7JSwaeBERvhVjezZodluDMg6Bqwly6svmE55P1dI kD9b9Q4aCegl47BYPblCsR3jGVRXCq3lTmcmzJYHnoszkBmAbkj8hW9sfnBXMQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="E/i5dZO1"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710219870; a=rsa-sha256; cv=none; b=EcH0x1Q1ic59aHMDTYep9PW/1/UcT8jrrEE00rjKM4sMOzSLUklNc84D6rqr/vcmtDaZX5 GB7qYF2LvggBmGZfz67aMuSAgEgfSAL3qBNq509EKWbSkueCAENbHdpTpNg3x7bgI0kv6U BLmoko32Ji7BlHZEENRd0wTuGymqCwPf+tlzBE/uEv8XS8HeNQERovfAudc+f0oWahvWM1 IayAGMZ0v6ZyMh2SrltDnli3LsVIRJidPInxa23sA+tPMNmdpZT2Y5Z8hoZT/9C5pZueEH d/1mR14pn/9eGANMH57isH5RHiQ5WrSXkEQoffNvLk/jpbPmATCA46FVcD9WyQ== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E4F591DE6A for ; Tue, 12 Mar 2024 06:04:29 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjuIl-0000d9-QT; Tue, 12 Mar 2024 01:03:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjuIO-0000av-Nh for emacs-orgmode@gnu.org; Tue, 12 Mar 2024 01:03:29 -0400 Received: from mail-qt1-x836.google.com ([2607:f8b0:4864:20::836]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rjuIM-0000S5-Mz for emacs-orgmode@gnu.org; Tue, 12 Mar 2024 01:03:24 -0400 Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-42e323a2e39so44598081cf.1 for ; Mon, 11 Mar 2024 22:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710219801; x=1710824601; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Z2yuVyOCwH8aqZF14lJ2DpxuZzgQoUVn0XApQbmls64=; b=E/i5dZO19WnNiUZIclsbA/DnMlEVa7x13/RtjHTPmmqjzxfmWBqD4MFEQjK0EgCken AaN3Ni1N9Anf5cDB1117qqFWZzfm1K+PDZpEUU47R2CWPEjNZESkCibT26TTojGyrQfh w3FmzUqQgM+/BaZ4vnER3ovpj0r33bnJTkj9F2Y9jXqcysuf8jBj90mxX8et+XmfnUyo CeV56aAEFjgIJWFoKwrG2af7MTNpDJWlMIXTK2K7eCzsnY7MzRSXxXM1VwiCj1I9wXXd iuFwFK9NfCCXnComQu+9PxB9SJM+2ac33h6LgEF1CgSHAmwuAX5vxmvIS2QzXTU22W07 E9sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710219801; x=1710824601; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Z2yuVyOCwH8aqZF14lJ2DpxuZzgQoUVn0XApQbmls64=; b=uTw15A1TKcFQN/agKTrqP58BuXDGGAjuVz8Unkt/Qtjndd3T83ITH4UBg2wa7kbDoP 8Ehng0OI2EBCFYeCnVgFhU30Ti273mkPIpW3++MtXPRLSY2MA+slOoBjPkkUkl6hKEwr ZLE4iB5xNrTFKauXl9jRPgW7v6gmv86XfO8z1B70Mu5GO0nFAkt72p2PkhActGNjGiHQ yZIOVw+8mldDKMOsnzUk8WppVcjYIZHpG6PQTROfnxmZGgI/TVv1/7ihwe5MlBcS551a 6WY40iRW7I5+mSakzOOZG8mtbEGSlbSk8RlhmsoppwOLE/9qwhYWnlwolceGiknD0srY nBwQ== X-Gm-Message-State: AOJu0Yx/y7u9e6GjM21l/wUqIFgGn3BTbMLBEMvYEw+fMv4fOFkkR7W1 df2PS9G2+XKMnFgyIIw6sM6VcoOuatJJPYokPR9TNtPFELCe/aF8igJEGf7U5W539cqheuaZHED Zn9/AsBxOESwshx15KgcuiAGvTqg7WKctJvLGjD+K X-Google-Smtp-Source: AGHT+IEd6Y68I6HmlfxjGm61JlynUTye2JZZFmpOzX2nUykaf7Lf1umb1TON/UoOiYXscO2C8Dl+V+xYlgy3rvAUu+c= X-Received: by 2002:a05:622a:293:b0:42e:f69e:b699 with SMTP id z19-20020a05622a029300b0042ef69eb699mr15526646qtw.8.1710219800833; Mon, 11 Mar 2024 22:03:20 -0700 (PDT) MIME-Version: 1.0 From: Laurence von Bottorff Date: Tue, 12 Mar 2024 00:03:10 -0500 Message-ID: Subject: org-id-locations as a large-scale database store? To: emacs-orgmode Mailinglist Content-Type: multipart/alternative; boundary="000000000000b7755d06136f9379" Received-SPF: pass client-ip=2607:f8b0:4864:20::836; envelope-from=borgauf@gmail.com; helo=mail-qt1-x836.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.56 X-Spam-Score: -8.56 X-Migadu-Queue-Id: E4F591DE6A X-TUID: HRBnfmFM4XRP --000000000000b7755d06136f9379 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? --=20 =E2=A8=BD Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com --000000000000b7755d06136f9379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been using a package called org-brain that is usi= ng, I'm all but certain, the org-id-locations file as its database to s= tore 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 I= D 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 appa= rently whatever is in my org directory and has a=C2=A0PROPERTIES drawer wit= h ID field winds up in .org-id-locations represented as plists in one big l= ist,=C2=A0one for each file that has one or more drawers. But you knowledge= able 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-3= 7db94fa9053" "6809202d-9a4c-4ed0-87fb-798676f448fe" "f2= 149157-6ba1-4e24-81c3-4e070fcc5de8" "5b7c2d9a-2df8-450a-a0c8-9d3b= 8e703044" "f3031b9f-3708-493d-9546-f489835c9f17") ("~/D= ropbox/org/orgb_fassungen/Fassungen.org" "e9b683af-90b1-4ece-9afd= -18dc28a9fab2")...)

where, e.g., inside t= he file=C2=A0FassungenDesc.org there are many org headings, each with a PRO= PERTIES/ID drawer -- and they're all associated to=C2=A0FassungenDesc.o= rg 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 al= l that scalable,=C2=A0not really intended=C2=A0for such a big thing. I saw = another emacs graph database (h= ttps://github.com/toshism/netz) that uses h.el hash to store graph vert= ices 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 e= ntries each (over a thousand perhaps per file) representing vertices. What = would be a better way of databasing org files and headings? The=C2=A0PROPER= TIES/ID drawer idea is fine, but not throwing it all in .org-id-locations, = right?

Ancillary: If I move or delete .org-id-loca= tions, 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= ?

--
=
=E2=A8=BD
Lawrence Bottorff
Grand Mar= ais, MN, USA
--000000000000b7755d06136f9379--