summaryrefslogtreecommitdiffstats
path: root/2022/talks/sqlite.md
diff options
context:
space:
mode:
authorSacha Chua <sacha@sachachua.com>2022-12-08 20:18:23 -0500
committerSacha Chua <sacha@sachachua.com>2022-12-08 20:18:23 -0500
commitc6c2d25cb561946e993e5dc5919afed8017cd087 (patch)
tree28d4221508f2e698c770eac658480ecf1e0426ef /2022/talks/sqlite.md
parentced1900a69df997596547d7edf69590f57decaba (diff)
downloademacsconf-wiki-c6c2d25cb561946e993e5dc5919afed8017cd087.tar.xz
emacsconf-wiki-c6c2d25cb561946e993e5dc5919afed8017cd087.zip
add etherpads to wiki pages
Diffstat (limited to '2022/talks/sqlite.md')
-rw-r--r--2022/talks/sqlite.md126
1 files changed, 126 insertions, 0 deletions
diff --git a/2022/talks/sqlite.md b/2022/talks/sqlite.md
index bba9503f..49e756ea 100644
--- a/2022/talks/sqlite.md
+++ b/2022/talks/sqlite.md
@@ -29,6 +29,132 @@ the advantages of the triple design are explained.
For more information and the packages discussed here, see the
[triples](https://github.com/ahyatt/triples) and
[ekg](https://github.com/ahyatt/ekg) pages.
+# Discussion
+
+## Notes
+
+- <https://github.com/ahyatt/triples>
+- <https://github.com/ahyatt/ekg>
+- <https://www.gnu.org/software/hyperbole/man/hyperbole.html#Implicit-Buttons> -
+ discussed in the next talk could really help simplify access to your
+ triples and ekg primitives; have a look when you have time.
+
+## Questions and answers
+
+- Q:  To what extent did Datomic influence the design of triples? 
+ <https://www.datomic.com/>
+ - A: I wasn\'t aware of Datomics, but I think both triples and
+ Datomics are influenced by RDF & trends in Knowledge Graph
+ construction in the industry.  I took a look at that page, and
+ one interesting thing they do is (AFAICT) store edits to the
+ database instead of actual values, allowing you to reconstruct
+ the database or go forward or backward in time.  This is very
+ interesting, and I\'m thinking of ways to make the database
+ safer, but not sure if I can get to such sophisticated
+ properties in this implementation. 
+- Q:built into Emacs? nice. multiple schemas (so to say
+ differentiation of \"databases\" (if you will so) are possible with
+ that built-in instance?
+ - A: Yes, with emacs 29. Full-featured with multiple databases,
+ transactions, etc.
+- Q:What about collaborative editing whith this? Multiple computers
+ with multiple emacs like crdt.el with org mode?
+ - A: Database are great for more async collaboration, multiple
+ people / processes can add to the repository at the same time. 
+ But I think it\'s not going to be a great solution for multiple
+ users modifying  the same buffer.
+- Q:What about using this on multiple computers? How would you
+ syncronize the data?  (This is a minor problem in org-roam where if
+ you share files between multiple computers, their SQLite databases
+ get out of sync and require M-x org-roam-db-sync to rebuild the
+ SQLite database.)
+ - A: This is an unsolved problem, one that I\'m interested in
+ looking into.  There possibly are standardized db solutions to
+ this, but I don\'t yet know what they are.
+- Q: With EKG what about views like org roam node mind map view? Or
+ org mode virtual view for integration with other org packages?
+ - A: This is possible, it just needs to interface with the
+ database in a different way.  It\'s all graphs, so really any
+ triple library might be a good fit for this.
+- Q:  Are you planning to further develop EKG? It is highly
+ interesting to me, I do prefer SQLite over text.
+ - A: Andrew is using it; not ready for general use but quite soon
+ \-- towards the end of  the month! Still in exploratory mode
+ though. Still thinking about (some of) the fundamental
+ concepts. 
+- Q: Is it then possible to combine the triples DB with some custom
+ tables in the same SQLite file? (e.g. to build a log table next to
+ the triples tables for quick query of event data)
+ - A: You could do that. AT the moment it\'s just one table
+ (triples). It\'s designed to be one table in one DB \-- beware
+ of consistency issues if you add further tables, which you can
+ definitely do.
+- Q: What are your thoughts on adding a timestamp attribute to triples
+ so that the DB becomes append-only and by default you return the
+ latest fact for a subject/object pair?
+ - Q+ -\> Use is to keep a record - you don´t delete? e.g. you get
+ all past addresses of a person or all past versions of a given
+ fact. Even version control for notes.
+ - A: I haven\'t thought of that / not seen in other triple stores
+ - A: Be ware that these DBs already take quite a bit of space
+ - A: may make synchronization easier
+- Q: can ordinary lisp data types (lists, symbols, etc) be stored in
+ the data base
+ - A: Yes, if you don\'t specify, it defaults to a list. Not sure
+ that was the right design choice; lists map to rows with a
+ hidden index column. emacs-sql and this also represent most
+ things as strings. 
+- Q: beyond note taking what kind of packages do you think would
+ benefit from triples library?
+ - A: Anything where you have lisp forms stored in a file would
+ probably be better implemented via a database.  And the triples
+ library makes this easy and standardized.  So, for example BBDB,
+ which is a \"database\" should actually be in a database.  And
+ then you might want to annotate, tag, etc, so having be in one
+ big database makes a lot of sense to me, because I think all
+ this kind of info wants to live together. 
+- Q: Are you trying to create a PIM with EKG?  What information do you
+ primarily want to manage?
+ - A: Yes, I think many uses of emacs is in line with PIM, and
+ those use-cases are a good fit for triples / ekg.  Notes,
+ people, projects, maybe even being able to integrate with org
+ and manage TODOs there as well.
+- Q: What about using other databases programs Postgres mongoDB etc..
+ \[see last q too, but I guess you refer to other relational, e.g.
+ Postgresql\]
+ - A: Those could work, maybe the triples library would work via
+ emacsql with those, but I haven\'t tested it.  I\'m not sure
+ what the benefit would be, typically these database tend to be
+ simple and small, so a more full-featured DB is probably
+ overkill.  MongoDB and those kinds of row-oriented databases
+ probably wouldn\'t be a good fit, but I haven\'t tried it.
+- Q: What is your preferred reference to understand triples/graph dbs?
+ (e.g. think better about schema design)
+ - A: I know from using them / talking about them. I will come back
+ with some references!
+- Q: Will it slow down with a growth of database?
+ - A: there is a tradeoff \-- triples gives you a standard schema,
+ but you lose the power of getting things in one SQL expression -
+ which makes it slow. But I have a bunch of data (2yrs of
+ org-roam usage) and it is still very fast. These limits exist,
+ but the usual rate of content creation is not large enough to
+ hit the limits.
+- Q: What are your thoughts on allowing for a \"true\" graph-db
+ backend? (whatever the current best free software alternative to
+ neo4j is, I guess). 
+ - A:  In my usage, the graph DBs tended to be slow and somewhat
+ clumsy in usage, we returned every time to SQL \[please reword
+ if appropriate\]. At the moment not a glaring need (for the
+ quantities of data people manage in Emacs).
+- Q: How hungry did you get while writing and recording this?
+ - A: I forgot that I used recipes as an example in my demo! 
+ org-roam / ekg and other things are a great way to cook better,
+ BTW.  When you make a recipe, write a org-roam daily (or in ekg,
+ an entry tagged with the date and the recipe) with notes about
+ how it went, what could be better, etc.  Then you can later see
+ the recipe and notes on it at once, which helps you further
+ refine the recipe.
+
[[!inline pages="internal(2022/info/sqlite-after)" raw="yes"]]