Re: Org and Hyperbole

[Jean Louis <bugs@gnu.support>]

* David Masterson <dsmasterson@gmail.com> [2022-10-10 19:55]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Robert Weiner <rsw@gnu.org> [2022-10-09 00:06]:
> >> There are many reasons for this including limits in many
> >> organizations of the file types that may be transferred through
> >> common protocols and the difficulty of maintaining relational
> >> database or structured file type schemas across time.
> >
> > I can't see how relational database is more difficult to maintain then
> > for example Emacs itself. Emacs is master of difficulties for computer
> > user. For example I have not touched configuration files for
> > PostgreSQL since years, if not decades. I start wondering why.
> 
> The issue here is distribution.  Databases tend to be centralized and
> heavy weight.

What does it mean centralized in this context? Majority of Relational
databases that I know have built-in collaboration features so that
people may access them from any part of the world; many have
replication features. I am not sure if "centralization" even fit into
the context.

> Here, we're simply looking for a standard way to capture an image
> (or more) with a task/note and tranport it back to your main Org
> file (a la Org Mobile or ...).  Org is lightweight in this area
> which is good and bad.

Regarding sizes:
================

$ du -skh .emacs.d/elpa/org-20201216/
11M	.emacs.d/elpa/org-20201216/

Database like   : sqlite3
Installed Size  : 7.55 MiB

Reference:

Relational database - Wikipedia:
https://en.wikipedia.org/wiki/Relational_database

You have misconception of what is lightweight or what is not or what
is difficult, I guess it comes simply from not trying it out. 

There is no "standard" way of taking notes, especially not in Org,
neither in Emacs environment, or generally for people.

Creating tables is pretty, new Emacs development has got SQLite built in:

(defun my-create-table-notes ()
      (rcd-sqlite "CREATE TABLE notes (
                      notes_id INTEGER NOT NULL PRIMARY KEY,
                      notes_datecreated TEXT NOT NULL DEFAULT (datetime()),
                      notes_datemodified TEXT NOT NULL DEFAULT (datetime()),
                      notes_name TEXT NOT NULL DEFAULT '>>>EDIT<<<',
                      notes_type INTEGER NOT NULL REFERENCES notetypes DEFAULT 1,
                      notes_text TEXT)"
		  rcd-people-sqlite-db))

Making a function to add a note is easy:

(defun rcd-db-table-sqlite-notes-insert-new-row ()
  "Add new note."
  (interactive)
  (let* ((name (read-string "Note name: "))
	 (prompt (format "Description about `%s': " name))
	 (note (string-edit "" "" 'ignore))
	 (sql (format "INSERT INTO notes (notes_name, notes_text)
                        VALUES (%s, %s) RETURNING notes_id"
		      (rcd-sqlite-escape-string name)
		      (rcd-sqlite-escape-string note)))
	 (id (rcd-sqlite-first sql rcd-people-sqlite-db)))
    id))

(defalias 'notes-add 'rcd-db-table-sqlite-notes-insert-new-row)

Viewing, listing, getting it back, making agendas, all that works
with so much less coding, works, less errors, and more speed.

Exporting to Org is easy:

(insert "\n\n"
	(rcd-sqlite-first "SELECT group_concat('** ' || notes_name || '\n\n' || notes_text,'\n\n') 
                           FROM notes 
                           ORDER BY notes_datecreated" rcd-people-sqlite-db))

** Something

My note #1

** My other heading

My note #2

** Something I knew before

My note #3

1

As Org users already wish and want to have structured properties,
tags, headings, links, tables, then it is right way to think that
with Emacs 29 and SQLite built-in, many things will become
easier.

Let us say keeping list of information such as accounting,
expenses, invoices, tasks, notes, etc. for any type of
information database has no ambiguity about structured
information, errors are minimized, programming efforts minimized. 

Pitfall would be that we would not have much discussion like now,
as with less bugs, there is less talk.

Imagine Org heading like this:

* My heading
  :PROPERTIES:
  :DB-ENTRY: :my-remote-host:my-database:my-org-table:id:1234
  :END:

Then imagine a pre-processor before saving the file or a hook for
saving Org file. Each time that file is saved, the heading entry could
be updated on remote host, database, table with ID 1234.  It could be
distributed, assigned, sent, easier shared, because data is
better estructured,

Or it could be updated in a local database.

Or it could be used to keep any kind information related to Org
heading. That is glue between the text file and well structured and
non ambiguous database.

If Org has mechanism to parse links in a file, a save hook could parse
them and store in database table for backlinks. 

Sometimes URL change, imagine Org link like: dbid:1234 that remains
immutable and which fetches the underlying dynamically updated URL.

If some Org headings are stored in the database, they may be updated
in Org file automatically.

Linking to Org headings could become so much more deterministic, as
one would link to unique ID in the database, no matter how heading is
named or where is it stored.

Collaboration door is open with networked databases. Concurrent access
to Org headings, links, contacts, becomes possible. Wide range of
options.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/