From: John Kitchin <jkitchin@andrew.cmu.edu>
To: emacs-orgmode@gnu.org
Cc: Bastien <bzg@gnu.org>, "Jose E. Marchesi" <jemarch@gnu.org>
Subject: Re: Exploring properties
Date: Tue, 25 Feb 2020 08:35:22 -0500 [thread overview]
Message-ID: <m2y2sqpz6t.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <20200225025847.hy7k7a3zqvh5wjgm@rewasi>
You might take a look at ebib, which is something like this for bibtex
files (also a plain text db). You can bend bibtex into being a database,
with custom entry types. What ebib does for bibtex might also be
possible for recutils too.
Similarly, bbdb offered an emacsy interface to a database of contacts (I
think just stored as elisp code).
elfeed has a git like database structure it uses to store things in, and
a front-end for displaying them.
For recutils, one could make a temporary org buffer full of recutil
entries in org syntax. Then, you could edit it, and write it back out, I
guess from a save-buffer-hook. The main benefit of this in my mind is
editing many records at a time, leveraging the search/navigation/outline
view of org-mode. I guess a row in a table per entry is all that could
be reliably done without a custom template that would allow you to
create headings per row. A table might be awkward for multiline entries
though. There is already a rec-mode with recutils that provides features
for editing, navigating, etc. within a rec file. I guess you can't edit
several entries at a time though.
The downside of headings might be then you also need custom code to
write it out. I guess this also goes by creating a list of sexp entries
that can be written out.
One simple application might be a recutils contact database, based on
org-contacts. These are basically headings with EMAIL properties, where
the heading is the contact name. You might also save tags in the entry,
and any other properties. You could store the body of the heading as
well. Some one will have to see how it scales with contacts, if it is
easy to search, etc.
Why contacts? org-contacts works ok, if you don't have too many, and
they aren't in too many files. I have 5000+ org-contacts spread all over
the place, so I have to use a cache (i.e. db) that is fast to query to
use them. If recutils was good for that, it might work for me.
Vikas Rawal <vikasrawal@gmail.com> writes:
> I don't know if this is useful. But this is what I could come up with. This might at least motivate somebody to think of other possible advantages/uses of building org-mode capabilities to interact with databases.
>
> Vikas
>
> ---
>
> Feature request: To build tools to facilitate using org-mode as a front-end for interacting with a database.
>
> The idea would be to use org-mode to select, insert and update records in a database. It is natural to think of recutils, a plain text database, as the database backend. But a more generalised solution may allow other choices of databases. With a text-based database backend like recutils, we could harness a version control system like git to semi-automate collaboraion.
>
> Why would one use org-mode for creating a database application? One can think of many advantages. But the biggest advantage (to me) would be that, in this setup, a multi-user database application can work without constant internet connectivity. You can query recutils files, insert/update records, and then let git deal with synchronisation across the team members.
>
> There are other advantages as well. We do not yet have a text-based,
> easy-to-deploy database application system. Recutils provides the
> infrastructure for a backend. But we do not have a fully-developed
> front-end system to interact with recutils. Org-mode is clearly best
> placed to provide the frontend for working with recutils.
>
> Needless to say, this would be particularly interesting to members of the org-mode/emacs fan-club. Over the last few years, org-mode has come to be used for many tasks that go way beyond what Carsten had in mind when he first built org-mode. From web-publishing to writing books, org-mode provides excellent tools. Being able to create and use databases from within org-mode would be a very useful addition to this toolkit.
>
> We already have tools that can be used to read data from recutils (and other databases) and create reports in org-mode. The missing feature is to be able to use org-mode to create/update records systemmatically.
>
> There are two possibilities here: to use org-mode tables or org-mode properties to interact with the database. The advantage of doing this using the org-mode properties is that the column-view of properties provides an easy to use interface for entering data. There is already a mechanism for defining "Allowed" values for any field which speeds up data entry and helps avoid typing errors.
>
> There are several challenges. Some of these are:
>
> 1. Extending "Allowed" values to specify type of data that can be recorded (numeric, char) or range of values.
> 2. How to deal with relationships/foreign keys. Can property inheritance be used to deal with at least simple foreign key constraints?
> 3. Org-mode macros provide {{{property(PROPERTYNAME)}}} syntax for macro replacement during export. But nothing as simple as this is available for use in source code blocks. Something like this would allow using some code to add/update records in a database. We should perhaps build on the property API or org-ql for creating something like this.
>
> If we can resolve some of these and creating a simple application for demonstration, it might help in showing the potential and identifying other challenges.
>
> On Mon, Feb 24, 2020 at 09:39:51AM +0100, Bastien wrote:
>> Hi Vikas,
>>
>> Vikas Rawal <vikasrawal@gmail.com> writes:
>>
>> > I am essentially thinking of org-mode providing an
>> > interface for feeding data to recutils.
>>
>> Yes, that would probably be useful.
>>
>> If you want to write a feature request, please write it as if the
>> reader does not know recutils and you precise use-case, so that we
>> understand all implication and motivate possible contributors.
>>
>> Thanks,
>>
>> --
>> Bastien
>>
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
prev parent reply other threads:[~2020-02-25 13:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 3:42 Exploring properties Vikas Rawal
2020-02-23 9:35 ` Bastien
2020-02-23 13:20 ` Vikas Rawal
2020-02-23 13:40 ` John Kitchin
2020-02-23 13:21 ` Vikas Rawal
2020-02-23 13:40 ` Bastien
2020-02-24 4:12 ` Vikas Rawal
2020-02-24 8:39 ` Bastien
2020-02-25 2:58 ` Vikas Rawal
2020-02-25 13:35 ` John Kitchin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2y2sqpz6t.fsf@andrew.cmu.edu \
--to=jkitchin@andrew.cmu.edu \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jemarch@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).