diff options
Diffstat (limited to '2022/captions/emacsconf-2022-sqlite--using-sqlite-as-a-data-source-a-framework-and-an-example--andrew-hyatt--answers.vtt')
| -rw-r--r-- | 2022/captions/emacsconf-2022-sqlite--using-sqlite-as-a-data-source-a-framework-and-an-example--andrew-hyatt--answers.vtt | 1535 |
1 files changed, 1535 insertions, 0 deletions
diff --git a/2022/captions/emacsconf-2022-sqlite--using-sqlite-as-a-data-source-a-framework-and-an-example--andrew-hyatt--answers.vtt b/2022/captions/emacsconf-2022-sqlite--using-sqlite-as-a-data-source-a-framework-and-an-example--andrew-hyatt--answers.vtt new file mode 100644 index 00000000..8391419c --- /dev/null +++ b/2022/captions/emacsconf-2022-sqlite--using-sqlite-as-a-data-source-a-framework-and-an-example--andrew-hyatt--answers.vtt @@ -0,0 +1,1535 @@ +WEBVTT + +00:00:02.000 --> 00:00:02.000 + + +00:00:02.000 --> 00:00:05.780 + All right. I think we're live. Thank you, Andrew, for the + +00:00:05.780 --> 00:00:06.480 + great talk. + +00:00:06.480 --> 00:00:09.040 + Folks, if you'd like to ask your questions, please post + +00:00:09.040 --> 00:00:11.280 + them on the pad. And at some point + +00:00:11.280 --> 00:00:13.340 + in like a minute or two, we'll also open this big blue + +00:00:13.340 --> 00:00:14.560 + button room if you'd like to + +00:00:14.560 --> 00:00:17.480 + join here directly and ask questions here. Take it away, + +00:00:17.480 --> 00:00:18.000 + Andrew. + +00:00:18.000 --> 00:00:25.200 + Yeah, thanks. So should I be reading the questions from the + +00:00:25.200 --> 00:00:26.880 + pad? Yeah. + +00:00:26.880 --> 00:00:28.400 + Yeah, that would be great. + +00:00:29.040 --> 00:00:34.760 + OK, so I see there's a question about is this built into Em + +00:00:34.760 --> 00:00:37.440 +acs? I guess that refers to SQLite. + +00:00:37.440 --> 00:00:41.630 + And is it possible to have multiple schemas, multiple + +00:00:41.630 --> 00:00:43.840 + databases? Yes, you could do all that + +00:00:43.840 --> 00:00:48.270 + with Emacs 29. SQLite is built in. You can open up multiple + +00:00:48.270 --> 00:00:50.000 + databases simultaneously and do just + +00:00:50.000 --> 00:00:53.460 + the normal things that you can do with databases. You can + +00:00:53.460 --> 00:00:54.640 + create whatever tables you want. + +00:00:55.440 --> 00:01:00.720 + You can create-- you can have transactions. So it's pretty + +00:01:00.720 --> 00:01:04.000 + full featured. With SQLite, + +00:01:04.000 --> 00:01:08.270 + there's also a notion of additions. You could kind of + +00:01:08.270 --> 00:01:10.880 + compile new things into it. And I'm not + +00:01:10.880 --> 00:01:14.560 + exactly sure to the extent that that is possible as well. + +00:01:14.560 --> 00:01:16.400 + So it's like how full featured of a + +00:01:16.400 --> 00:01:19.540 + SQLite is it? I'm not sure. But the basic stuff, you can + +00:01:19.540 --> 00:01:21.680 + certainly do. And that basic stuff is + +00:01:21.680 --> 00:01:26.860 + fantastic. Next question is, what about collaborative + +00:01:26.860 --> 00:01:29.920 + editing with this? Can you + +00:01:29.920 --> 00:01:35.070 + have multiple computers with multiple Emacs with org mode? + +00:01:35.070 --> 00:01:37.840 + I think it sort of depends. Yes, + +00:01:37.840 --> 00:01:41.640 + I mean, databases are fantastic for having multiple users + +00:01:41.640 --> 00:01:44.080 + doing multiple things at the same time. + +00:01:44.080 --> 00:01:48.990 + And they're really designed for this use case. So I would + +00:01:48.990 --> 00:01:51.760 + say, yes, you could have multiple + +00:01:51.760 --> 00:01:56.810 + editing of the database, multiple editing, whereas you see + +00:01:56.810 --> 00:02:04.160 + some [AUDIO OUT] probably not the best + +00:02:04.160 --> 00:02:06.830 + solution. I suspect it might be possible, but I wouldn't + +00:02:06.830 --> 00:02:08.720 + want to try it. I think it's better for, + +00:02:08.720 --> 00:02:12.660 + like, oh, you can have multiple processes, multiple users, + +00:02:12.660 --> 00:02:14.400 + perhaps contributing to the + +00:02:14.400 --> 00:02:17.610 + same database. And you're growing the database, but not + +00:02:17.610 --> 00:02:20.080 + such tight synchronous interactivity that + +00:02:20.080 --> 00:02:24.520 + I think you might be imagining here. What about using this + +00:02:24.520 --> 00:02:26.880 + on multiple computers? How do you + +00:02:26.880 --> 00:02:31.140 + synchronize your data? I don't know. I need to figure that + +00:02:31.140 --> 00:02:33.040 + out. I think there's a-- like, + +00:02:33.040 --> 00:02:36.470 + yes, you can synchronize your database in the same [AUDIO + +00:02:36.470 --> 00:02:38.320 + OUT] Emacs doesn't have any great + +00:02:38.320 --> 00:02:43.000 + solutions for this. That is, like, when-- let's say I want + +00:02:43.000 --> 00:02:45.680 + to synchronize the things I'm editing + +00:02:45.680 --> 00:02:49.280 + on Emacs with my phone. There's all sorts of various + +00:02:49.280 --> 00:02:52.320 + solutions. You could use Dropbox, Google + +00:02:52.320 --> 00:02:56.930 + Drive, these kinds of things. The database makes that a + +00:02:56.930 --> 00:02:59.600 + little bit harder in the sense that it's + +00:02:59.600 --> 00:03:04.400 + one giant database. I suspect there are interesting ways to + +00:03:04.400 --> 00:03:06.560 + do this, but I haven't explored this area + +00:03:06.560 --> 00:03:09.180 + yet. I think it's a great question, though, and I would + +00:03:09.180 --> 00:03:10.800 + like to investigate this further. + +00:03:10.800 --> 00:03:16.640 + Are you planning to further-- this is a new other question. + +00:03:16.640 --> 00:03:18.720 + Are you planning to further develop EKG? + +00:03:18.720 --> 00:03:22.330 + It's highly [AUDIO OUT] me, and I do prefer SQLite over + +00:03:22.330 --> 00:03:23.920 + Text. Thank you for buying into + +00:03:25.200 --> 00:03:29.280 + the vision. I really like to hear that. Yeah, I am + +00:03:29.280 --> 00:03:32.080 + personally using EKG. I am developing it. + +00:03:32.080 --> 00:03:36.940 + I don't think it's ready for general use yet. I'd like to + +00:03:36.940 --> 00:03:39.680 + get it to a state where it is ready + +00:03:39.680 --> 00:03:43.410 + for general use probably by the end of the month. I think I + +00:03:43.410 --> 00:03:45.600 +'ll have a lot of time. There's a pretty + +00:03:45.600 --> 00:03:50.500 + slow month. So that would be really nice. I've just added a + +00:03:50.500 --> 00:03:52.160 + bunch of stuff to it. + +00:03:53.360 --> 00:03:55.970 + I'm exploring. I think the difficult thing is not + +00:03:55.970 --> 00:03:58.000 + necessarily to make it production, + +00:03:58.000 --> 00:04:01.800 + like to make it stable and everything like that and to do + +00:04:01.800 --> 00:04:04.320 + all the developer things that you want + +00:04:04.320 --> 00:04:09.380 + to see in the state of the art era, but really, it's a + +00:04:09.380 --> 00:04:12.240 + different model of how to have notes. + +00:04:12.240 --> 00:04:16.860 + I'm still thinking about some of these fundamental concepts + +00:04:16.860 --> 00:04:18.080 +. It took me a long + +00:04:18.080 --> 00:04:22.030 + time to iterate on various designs before I came up with EK + +00:04:22.030 --> 00:04:24.240 +G, which I think is [AUDIO OUT] + +00:04:24.240 --> 00:04:27.200 + and so we're going to really see how this goes. But yes, + +00:04:27.200 --> 00:04:29.920 + look for it soon. I'll probably announce it + +00:04:29.920 --> 00:04:39.410 + and maybe on email. And then I will make it available + +00:04:39.410 --> 00:04:40.960 + probably maybe on + +00:04:42.000 --> 00:04:46.780 + new alpha is what I would like to do. Is it possible to + +00:04:46.780 --> 00:04:47.760 + combine the + +00:04:47.760 --> 00:04:51.610 + triples database with some custom tables in the same SQLite + +00:04:51.610 --> 00:04:56.240 + file? Yes. I'm sorry. Let me continue + +00:04:56.240 --> 00:04:59.670 + reading. You need to build a log table next to the triples + +00:04:59.670 --> 00:05:02.080 + table or a quick query of event data. + +00:05:02.080 --> 00:05:04.270 + Yeah, you certainly could do that. And I've been thinking + +00:05:04.270 --> 00:05:04.720 + of adding, + +00:05:05.520 --> 00:05:09.210 + like, just having a record of changes might be an + +00:05:09.210 --> 00:05:12.720 + interesting thing. But yeah, it's just one table + +00:05:12.720 --> 00:05:17.840 + and you really could use this one table called triples, the + +00:05:17.840 --> 00:05:22.000 + triples table, in any other database + +00:05:22.000 --> 00:05:24.230 + or with any other database. It's kind of designed to be its + +00:05:24.230 --> 00:05:26.080 + own database though. But yeah, you could + +00:05:26.080 --> 00:05:28.500 + certainly add things to the side and I can imagine people + +00:05:28.500 --> 00:05:29.840 + writing extensions that do + +00:05:30.560 --> 00:05:34.000 + add some tables to the side to do whatever. It's just that + +00:05:34.000 --> 00:05:37.680 + I think you want to be careful because + +00:05:37.680 --> 00:05:42.660 + that once you start doing that, you might want to, you don + +00:05:42.660 --> 00:05:45.040 +'t want to kind of duplicate information or + +00:05:45.040 --> 00:05:47.490 + start having things go out of sync. It's kind of nice just + +00:05:47.490 --> 00:05:49.600 + to have one kind of data. But I think + +00:05:49.600 --> 00:05:52.090 + in certain circumstances, like the kind you're thinking + +00:05:52.090 --> 00:05:54.320 + about, it'd be appropriate. Yeah, so + +00:05:54.320 --> 00:06:00.010 + seems like a good idea. And then I see this final question + +00:06:00.010 --> 00:06:02.800 + here, final for now. What are your + +00:06:02.800 --> 00:06:05.270 + thoughts on adding a timestamp attribute to triple so that + +00:06:05.270 --> 00:06:07.280 + the database becomes append-only and by + +00:06:07.280 --> 00:06:10.570 + default you return the latest fact for a subject-object + +00:06:10.570 --> 00:06:13.360 + pair? Oh, really interesting question. + +00:06:13.360 --> 00:06:19.560 + Let's just say I haven't thought of that and I'll have to + +00:06:19.560 --> 00:06:21.680 + think about it. I don't think, + +00:06:21.680 --> 00:06:26.110 + I haven't seen other triples databases do this. I'd be + +00:06:26.110 --> 00:06:28.000 + interested in what you thought + +00:06:28.000 --> 00:06:33.610 + would be some of the, what you thought might be some of the + +00:06:33.610 --> 00:06:34.960 + interesting + +00:06:34.960 --> 00:06:39.440 + things that come out of this. Yes, you can maybe go back in + +00:06:39.440 --> 00:06:41.760 + time, which is nice, + +00:06:41.760 --> 00:06:45.620 + but then it seems hard to do things like deletes. I guess + +00:06:45.620 --> 00:06:48.000 + you could have tombstones or something + +00:06:48.000 --> 00:06:51.110 + like that, but it becomes a little bit more complicated. + +00:06:51.110 --> 00:06:52.880 + And also just one thing is like, + +00:06:52.880 --> 00:06:55.390 + these kind of databases, I didn't really talk about this in + +00:06:55.390 --> 00:06:57.120 + the talk, but they take up a little + +00:06:57.120 --> 00:06:59.870 + bit of room and I'm a little bit reluctant to have them + +00:06:59.870 --> 00:07:01.760 + even more kind of heavyweight. + +00:07:01.760 --> 00:07:05.380 + On the other hand, perhaps this would go well with the + +00:07:05.380 --> 00:07:07.680 + question about synchronization. If you + +00:07:07.680 --> 00:07:11.840 + were to do as you suggest and have timestamped triples, + +00:07:11.840 --> 00:07:14.080 + synchronization actually becomes pretty + +00:07:14.080 --> 00:07:18.110 + easy. So definitely an interesting thought that I'll have + +00:07:18.110 --> 00:07:19.600 + to think a little bit more about. I + +00:07:19.600 --> 00:07:23.970 + would love to solve the synchronization problem. All right. + +00:07:23.970 --> 00:07:29.520 + I don't see any other, oh yeah, + +00:07:29.520 --> 00:07:33.740 + I don't see any other questions, but you can ask on this, + +00:07:33.740 --> 00:07:38.160 + on the big blue button or type in any + +00:07:38.160 --> 00:07:42.730 + other questions. Otherwise I think we might be done. Cool. + +00:07:42.730 --> 00:07:45.280 + And I will add that. I think we still + +00:07:45.280 --> 00:07:48.590 + have about like, I guess, 15 minutes or so of live Q&A talk + +00:07:48.590 --> 00:07:52.320 + for this talk on stream. If there are no + +00:07:52.320 --> 00:07:54.790 + questions, you're welcome to cut it short, but otherwise we + +00:07:54.790 --> 00:07:56.320 + have plenty of time. So yeah, if + +00:07:56.320 --> 00:07:59.910 + people want to get more questions in, please do. I'm just + +00:07:59.910 --> 00:08:01.680 + going to sit back and wait for the + +00:08:01.680 --> 00:08:06.000 + questions to roll in then. Sounds good. Thank you. + +00:08:06.000 --> 00:08:35.920 + All right. I see another question pop up. + +00:08:37.040 --> 00:08:37.040 + + +00:08:37.040 --> 00:08:41.400 + With EKG, what about views like org-roam-node-mindmap-views + +00:08:41.400 --> 00:08:44.080 +? Yeah. I personally have + +00:08:44.080 --> 00:08:47.280 + not found those views to be super helpful, but I know + +00:08:47.280 --> 00:08:49.680 + people like them a lot. I don't see any + +00:08:49.680 --> 00:08:52.800 + reason why you couldn't do this. It just would be a + +00:08:52.800 --> 00:08:56.000 + slightly different implementation. Like this + +00:08:56.000 --> 00:09:02.940 + stuff forms a graph. You can do whatever you, you know, you + +00:09:02.940 --> 00:09:05.920 + could easily transform it like that same + +00:09:05.920 --> 00:09:09.560 + org-roam UI. You just have to have like another sort of + +00:09:09.560 --> 00:09:12.160 + translation layer basically to kind of + +00:09:12.160 --> 00:09:16.450 + like figure out how to deal with the stuff in EKG or really + +00:09:16.450 --> 00:09:19.520 + anything with triples. Like fundamentally + +00:09:19.520 --> 00:09:23.240 + it's a graph database, so it lends itself naturally to + +00:09:23.240 --> 00:09:25.680 + things that you're going to be doing, + +00:09:25.680 --> 00:09:30.080 + that anything you're going to be doing with the triples + +00:09:30.080 --> 00:09:30.800 + library. + +00:09:32.400 --> 00:09:32.400 + + +00:09:32.400 --> 00:09:52.480 + [silence] + +00:09:52.480 --> 00:09:46.220 + I see another question. Can ordinary Lisp data types, Lisp + +00:09:46.220 --> 00:09:59.440 + symbols, etc. be stored in the + +00:09:59.440 --> 00:10:04.760 + database? Yes, they can. In fact, it's primarily like if + +00:10:04.760 --> 00:10:07.120 + you don't specify anything, it kind of + +00:10:07.120 --> 00:10:10.900 + defaults to a list. That's sort of, I'm not exactly sure + +00:10:10.900 --> 00:10:13.520 + that's the right design choice, but that's + +00:10:13.520 --> 00:10:19.230 + kind of, it seems like a lot of the times it, this kind of + +00:10:19.230 --> 00:10:24.000 + makes sense. Like what if I just added + +00:10:24.000 --> 00:10:27.000 + like a title, I think, if I remember. I did add a title, + +00:10:27.000 --> 00:10:29.360 + but I'm trying to remember. If I just added + +00:10:29.360 --> 00:10:33.770 + the notion of like having a title to EKG and I believe that + +00:10:33.770 --> 00:10:36.240 +'s a list. Because you think about it, + +00:10:36.240 --> 00:10:39.160 + you could maybe have alternate titles or multiple titles. + +00:10:39.160 --> 00:10:40.880 + So these are ordered lists and so it kind + +00:10:40.880 --> 00:10:44.380 + of stores it. So basically what happens is you store in the + +00:10:44.380 --> 00:10:46.560 + list of like, but each list item is + +00:10:46.560 --> 00:10:49.910 + a separate row in the table and it has, we call them tri + +00:10:49.910 --> 00:10:52.880 +ples, but there's actually one more column + +00:10:52.880 --> 00:10:54.720 + that I don't talk about a lot because it just confuses the + +00:10:54.720 --> 00:10:56.160 + story. But in this case it's relevant + +00:10:56.160 --> 00:10:59.040 + because there you just say what the index is of the item + +00:10:59.040 --> 00:11:01.120 + that you're doing it. So like you'd be + +00:11:01.120 --> 00:11:09.150 + subject and then the predicate would be title in a sense. + +00:11:09.150 --> 00:11:12.400 + And then title one and then like, + +00:11:12.400 --> 00:11:15.860 + okay, that's index one on the fourth column. And then same + +00:11:15.860 --> 00:11:17.200 + thing with the other items. + +00:11:17.840 --> 00:11:24.090 + You can store symbols, SQLite and Emac SQL allow you to + +00:11:24.090 --> 00:11:27.920 + sort of kind of, well, Emac SQL kind of + +00:11:27.920 --> 00:11:31.130 + naturally lets you store lots of different things. And SQL + +00:11:31.130 --> 00:11:33.840 +ite, I kind of had to do something that + +00:11:33.840 --> 00:11:39.790 + was very similar to Emac SQL. Emac SQL, in SQL, you have to + +00:11:39.790 --> 00:11:43.120 + just, in your database, it basically + +00:11:43.120 --> 00:11:47.000 + has to be string. Like almost everything besides the predic + +00:11:47.000 --> 00:11:49.120 +ates, like the object has to be a string + +00:11:49.120 --> 00:11:52.250 + because it could really be anything. And the subject has to + +00:11:52.250 --> 00:11:53.840 + be a string because it could be + +00:11:53.840 --> 00:12:00.490 + anything. And because of that, we kind of have to make sure + +00:12:00.490 --> 00:12:04.080 + that we kind of have to just store + +00:12:04.080 --> 00:12:06.840 + things in a certain way. Like symbols are just strings and + +00:12:06.840 --> 00:12:10.720 + lists. You could even have a list, + +00:12:12.640 --> 00:12:17.810 + you could have really any list expression as a subject, + +00:12:17.810 --> 00:12:21.600 + right? But it gets just written to a + +00:12:21.600 --> 00:12:27.720 + string and then it gets, when it gets read, it basically, + +00:12:27.720 --> 00:12:30.960 + if it's just a string, it gets read + +00:12:30.960 --> 00:12:36.370 + basically as a list symbol or expression. And if it's a + +00:12:36.370 --> 00:12:39.840 + string, it's a string with a string inside, + +00:12:39.840 --> 00:12:44.130 + that is like the string actually has quotes on either end. + +00:12:44.130 --> 00:12:46.000 + Then we say it's actually a string. + +00:12:46.000 --> 00:12:48.770 + That's how kind of the internal implementation works. And + +00:12:48.770 --> 00:12:50.320 + that's what Emac SQL does as well. + +00:12:50.320 --> 00:12:55.040 + For those who are not familiar, Emac SQL is like this other + +00:12:55.040 --> 00:12:58.560 + way to kind of interact with SQL in + +00:12:58.560 --> 00:13:02.210 + your databases and it works well with SQLite and allows you + +00:13:02.210 --> 00:13:04.400 + to do things like store numbers and + +00:13:05.600 --> 00:13:08.960 + lists as well. And it does this exact same thing. So we try + +00:13:08.960 --> 00:13:10.320 + to keep compatibility. + +00:13:10.320 --> 00:13:18.910 + So you could start a database in Emacs 28 using Emacs SQL + +00:13:18.910 --> 00:13:23.440 + and then you could read it with Emacs 29 + +00:13:23.440 --> 00:13:27.430 + using the built in SQLite. That's the hope. I mean, I have + +00:13:27.430 --> 00:13:28.720 + tests, but I don't think anyone + +00:13:28.720 --> 00:13:35.050 + has actually tried to do that exact thing yet. Let's see. + +00:13:35.050 --> 00:13:39.040 + Are there any other new questions? + +00:13:39.040 --> 00:13:44.240 + Oh, there are some. Beyond note taking, what kind of + +00:13:44.240 --> 00:13:45.360 + packages do you + +00:13:45.360 --> 00:13:49.680 + think would benefit from a triple library? I think, + +00:13:49.680 --> 00:13:53.830 + I mean, I think it's generally just an easy way to store + +00:13:53.830 --> 00:13:54.880 + things. So + +00:13:56.800 --> 00:14:03.200 + anything in which you, think of packages that have to store + +00:14:03.200 --> 00:14:03.440 + like + +00:14:03.440 --> 00:14:09.440 + list expressions on the side. Like for example, like BBDB, + +00:14:09.440 --> 00:14:11.200 + if you've used that, + +00:14:11.200 --> 00:14:14.110 + it's just a, it is a database. It's the big brother + +00:14:14.110 --> 00:14:17.200 + database. It's not in a database because + +00:14:17.200 --> 00:14:19.890 + it was written before. Like there was an easy way to use + +00:14:19.890 --> 00:14:22.480 + databases in Emacs. Like that should, + +00:14:22.480 --> 00:14:24.640 + that could definitely, like you don't need the triples + +00:14:24.640 --> 00:14:26.160 + library, but you could easily do this + +00:14:26.160 --> 00:14:31.120 + in the triples library. And I would kind of think triples, + +00:14:31.120 --> 00:14:33.120 + you know, just takes care of a lot of + +00:14:33.120 --> 00:14:37.280 + things and gives a little option over everything. So I mean + +00:14:37.280 --> 00:14:39.760 +, there's all sorts of things like, + +00:14:39.760 --> 00:14:42.210 + as I, as I kind of demoed like bookmarks, like why are book + +00:14:42.210 --> 00:14:43.920 +marks not in the database? They should be. + +00:14:43.920 --> 00:14:48.150 + So I think if you just look around and look at all these, + +00:14:48.150 --> 00:14:50.640 + all these things as, + +00:14:51.280 --> 00:14:55.680 + as just, just dumping, dumping list expressions to a file, + +00:14:55.680 --> 00:14:57.440 + those probably + +00:14:57.440 --> 00:15:01.870 + SQLite and, and, you know, maybe triples would be a useful + +00:15:01.870 --> 00:15:03.200 + way to do that. + +00:15:03.200 --> 00:15:08.720 + Are you, another question, are you trying to PIM? I think + +00:15:08.720 --> 00:15:11.120 + that means personal information management + +00:15:11.120 --> 00:15:16.160 + with EKG. And what information do you want to manage? I'm + +00:15:16.160 --> 00:15:17.120 + kind of wondering + +00:15:18.720 --> 00:15:21.400 + how I, what I want to do, but like, as I just said in the + +00:15:21.400 --> 00:15:23.440 + previous question, like, I think + +00:15:23.440 --> 00:15:26.960 + you should be storing everything. Yeah. Like libraries, + +00:15:26.960 --> 00:15:28.880 + like, yeah, actually, yeah. BBBB, + +00:15:28.880 --> 00:15:32.180 + you can store contacts and email addresses. And I would + +00:15:32.180 --> 00:15:34.320 + like to, you know, why, if you're storing + +00:15:34.320 --> 00:15:37.110 + that, then it's kind of natural, like, oh, well, you know, + +00:15:37.110 --> 00:15:38.880 + sometimes I want to have a annotation. + +00:15:38.880 --> 00:15:41.380 + I want to write something about this person and, you know, + +00:15:41.380 --> 00:15:44.000 + maybe I want to have something and have, + +00:15:46.400 --> 00:15:48.930 + you know, maybe I want to tag this person. Maybe I want to, + +00:15:48.930 --> 00:15:53.200 + maybe I want to have notes that refer + +00:15:53.200 --> 00:15:55.700 + to this person. So like, it all starts to look like one + +00:15:55.700 --> 00:15:57.280 + giant database when I, when you kind + +00:15:57.280 --> 00:16:01.120 + of think about it a lot, which is kind of why in a, if you + +00:16:01.120 --> 00:16:04.800 + look at the develop, develop branch of + +00:16:04.800 --> 00:16:08.290 + triples, I, I'm work, I think what's going to be in the + +00:16:08.290 --> 00:16:10.400 + next version is, is going to be a + +00:16:10.400 --> 00:16:14.110 + standardized place to, to have a database. That is, you can + +00:16:14.110 --> 00:16:17.360 + just connect to a, to a, the standard + +00:16:17.360 --> 00:16:19.360 + database and you don't have to worry about where the + +00:16:19.360 --> 00:16:21.280 + database is. We'll keep track of that for you. + +00:16:21.280 --> 00:16:27.540 + And, and then everything should be working very easily and + +00:16:27.540 --> 00:16:30.320 + like allow this kind of collaborative + +00:16:30.320 --> 00:16:32.770 + use of, of these things. So like, yeah, it could be a + +00:16:32.770 --> 00:16:34.720 + personal information manager that has all + +00:16:34.720 --> 00:16:37.330 + sorts of information because I think that's what people + +00:16:37.330 --> 00:16:39.440 + tend to use Emacs for is that, you know, + +00:16:39.440 --> 00:16:43.610 + I have my own notes, my own contacts, my own tasks, you + +00:16:43.610 --> 00:16:46.080 + know, why aren't tasks in, tasks should + +00:16:46.080 --> 00:16:49.820 + also perhaps be in, in, in the database. Like, yeah, it's + +00:16:49.820 --> 00:16:52.000 + kind of, org mode is completely awesome, + +00:16:52.000 --> 00:16:56.110 + like really incredible. And it's, it's nice to mix to do's + +00:16:56.110 --> 00:16:58.480 + with things with text, but sometimes + +00:16:58.480 --> 00:17:01.850 + maybe you just want to do's that are not with text and + +00:17:01.850 --> 00:17:04.160 + maybe those could be also in the database. + +00:17:04.160 --> 00:17:06.050 + I don't know. It's just things I, things I'm thinking about + +00:17:06.050 --> 00:17:07.200 +. I'm not sure how far I want to + +00:17:07.200 --> 00:17:12.160 + take that. Another question. What about using other + +00:17:12.160 --> 00:17:16.000 + database programs like Postgres, MonoDB? + +00:17:16.000 --> 00:17:27.550 + You, so I think you could, yes, you could do that. I don't + +00:17:27.550 --> 00:17:29.920 + see it's a, I don't know why you, + +00:17:29.920 --> 00:17:32.720 + I don't know if there's any advantage to doing this. Like + +00:17:32.720 --> 00:17:35.280 + SQLite is kind of nice because it is + +00:17:35.280 --> 00:17:38.490 + light. It is kind of, it is built into Emacs and we don't + +00:17:38.490 --> 00:17:39.760 + really need anything incredibly + +00:17:39.760 --> 00:17:42.210 + sophisticated here. Just having a database is like such a + +00:17:42.210 --> 00:17:43.680 + higher level of sophistication than + +00:17:43.680 --> 00:17:47.500 + what we've been doing in Emacs are so far. Then you know, I + +00:17:47.500 --> 00:17:50.000 + think the other stuff might be overkill, + +00:17:50.000 --> 00:17:52.800 + but I see no reason why it wouldn't work. I just don't + +00:17:52.800 --> 00:17:54.640 + really see if there's really any big + +00:17:54.640 --> 00:18:00.620 + advantages. What is your preferred reference to underscan + +00:18:00.620 --> 00:18:04.960 + triples graph DBs? To sort of think + +00:18:04.960 --> 00:18:07.330 + about better schema design? Oh, that's a really awesome + +00:18:07.330 --> 00:18:12.480 + question. And I would, I don't, I don't + +00:18:12.480 --> 00:18:15.570 + think I can answer that immediately. I kind of know all + +00:18:15.570 --> 00:18:17.520 + this stuff from talking to people + +00:18:17.520 --> 00:18:21.730 + basically, instead of like reading things. And like in my + +00:18:21.730 --> 00:18:25.040 + work, I use these triples. That is, + +00:18:25.040 --> 00:18:28.100 + that's kind of like, you know, I kind of work on a + +00:18:28.100 --> 00:18:30.560 + knowledge graph. So I just have a, from, + +00:18:30.560 --> 00:18:35.860 + you know, working knowledge of how these things work. So, + +00:18:35.860 --> 00:18:38.400 + but it is an awesome question that let + +00:18:38.400 --> 00:18:41.530 + me, let me look into it after I kind of finished this and I + +00:18:41.530 --> 00:18:43.440 +'ll, I'll try to fill it in, in the, + +00:18:43.440 --> 00:18:47.210 + in the either pad that is connected to this talk. So thank + +00:18:47.210 --> 00:18:49.200 + you for that great question. + +00:18:49.200 --> 00:18:53.960 + So another question, will it slow down with the growth of a + +00:18:53.960 --> 00:18:56.960 + database? Yeah, I need to do + +00:18:56.960 --> 00:19:00.040 + tests about this. Cause I'd like to see like how much, how + +00:19:00.040 --> 00:19:01.360 + much the database blows up, + +00:19:01.360 --> 00:19:05.120 + how much it slows down for sure. Triples is not the most + +00:19:05.120 --> 00:19:07.360 + efficient way. It's not even close + +00:19:07.360 --> 00:19:10.650 + to being a greatly efficient way to store data for doing + +00:19:10.650 --> 00:19:13.120 + any arbitrary things. But what it is, + +00:19:13.120 --> 00:19:17.510 + it you're trading off standardization, which is, so you get + +00:19:17.510 --> 00:19:19.600 + standardization, but you lose, + +00:19:19.600 --> 00:19:24.880 + you lose the power of getting things in one SQL expression. + +00:19:24.880 --> 00:19:26.480 + So you often have to kind of like do + +00:19:26.480 --> 00:19:31.400 + a bunch of round trips and that's slow. However, I I'm + +00:19:31.400 --> 00:19:36.320 + using this now. I have a bunch of data + +00:19:36.320 --> 00:19:40.440 + and you know, quite a bit. I've, I kind of poured it over + +00:19:40.440 --> 00:19:42.720 + my old org Rome to, to EKG. + +00:19:42.720 --> 00:19:45.860 + And you know, I've been accumulating stuff in our room for + +00:19:45.860 --> 00:19:47.920 + like, you know, two years now, + +00:19:47.920 --> 00:19:52.510 + and it's pretty big, but it's very fast, really just no, no + +00:19:52.510 --> 00:19:55.200 + problems at all. So yes, I'm sure + +00:19:55.200 --> 00:20:00.750 + that there is a, a size in which it's too big to be fast. + +00:20:00.750 --> 00:20:04.400 + But I haven't hit it. And I suspect for + +00:20:04.400 --> 00:20:09.230 + most ordinary uses of, of, of Emacs, I doubt other people + +00:20:09.230 --> 00:20:12.160 + will hit it as well. I mean, it's kind of + +00:20:12.160 --> 00:20:14.380 + similar to, you know, when people think about org Rome and + +00:20:14.380 --> 00:20:15.760 + things like, well, you know, you're + +00:20:15.760 --> 00:20:17.980 + storing everything in one database, like how many notes + +00:20:17.980 --> 00:20:19.520 + could have possibly hold, like that's also + +00:20:19.520 --> 00:20:25.980 + going to get slow. Right. So yeah, it's, it's I think these + +00:20:25.980 --> 00:20:29.760 + limits exist, but people tend not to + +00:20:29.760 --> 00:20:32.480 + hit them and it's like, yes, this is going to get slow, but + +00:20:32.480 --> 00:20:34.320 + it'll certainly do better. I think that + +00:20:34.320 --> 00:20:38.850 + files in the file system. What are the, here's another + +00:20:38.850 --> 00:20:41.920 + question. What are your thoughts on + +00:20:41.920 --> 00:20:47.130 + allowing for a true graph DB backend? Whatever the current + +00:20:47.130 --> 00:20:50.480 + best free software alternative to Neo4j + +00:20:50.480 --> 00:20:54.710 + is, I guess. Okay. Great question. I've actually, yeah, I + +00:20:54.710 --> 00:20:57.360 + actually used graph databases and several + +00:20:57.360 --> 00:21:00.580 + companies I used to work for and you know, but we always + +00:21:00.580 --> 00:21:03.040 + ended up switching to SQL. I like it's, + +00:21:03.040 --> 00:21:08.000 + it's I can't, it's just at least for serious applications, + +00:21:08.000 --> 00:21:10.080 + they tended to be slow and + +00:21:10.880 --> 00:21:14.310 + lend themselves to a use that was not, that was very iter + +00:21:14.310 --> 00:21:16.480 +ative and not very well thought out. + +00:21:16.480 --> 00:21:23.880 + So however, I don't think it's as I said, with the last + +00:21:23.880 --> 00:21:28.720 + question for the way people want to, + +00:21:28.720 --> 00:21:31.090 + you know, the kind of data I think Emacs users will want, I + +00:21:31.090 --> 00:21:32.480 + think a graph database would work + +00:21:32.480 --> 00:21:36.610 + quite well. I don't know if there would be like, what are + +00:21:36.610 --> 00:21:38.720 + the advantages over triples + +00:21:38.720 --> 00:21:41.700 + aside from sort of just a more, you don't have to kind of + +00:21:41.700 --> 00:21:43.440 + even deal with the SQL layer, but like, + +00:21:43.440 --> 00:21:46.040 + I'm kind of, I'm kind of building, you know, with triples, + +00:21:46.040 --> 00:21:47.760 + we're sort of like, don't even worry about + +00:21:47.760 --> 00:21:50.220 + what the layer is, right? It's just, you don't even have to + +00:21:50.220 --> 00:21:51.920 + worry about SQL if you're just using + +00:21:51.920 --> 00:21:57.040 + kind of the normal functionality. So you can yeah. So, you + +00:21:57.040 --> 00:22:00.160 + know, maybe there are interesting + +00:22:00.160 --> 00:22:02.670 + implications for using a graph database, but I can't really + +00:22:02.670 --> 00:22:03.680 + think of any right now. + +00:22:03.680 --> 00:22:09.910 + It's a good question though. Thank you. - And I'll quickly + +00:22:09.910 --> 00:22:10.880 + add that we have about, + +00:22:10.880 --> 00:22:14.850 + I think two more minutes ish on this live stream. And then + +00:22:14.850 --> 00:22:17.120 + folks are welcome to either join here for + +00:22:17.120 --> 00:22:19.560 + continuing the Q and A or keep posting questions on the pad + +00:22:19.560 --> 00:22:21.040 + and you can continue here in this room + +00:22:21.040 --> 00:22:24.000 + after the stream moves on. - Okay. In that case, I'll, + +00:22:24.000 --> 00:22:28.320 + I will stick around until I don't get any more questions + +00:22:28.320 --> 00:22:30.080 + for a few minutes, then I'll probably + +00:22:31.200 --> 00:22:33.440 + log off. - Sounds great. Thank you. + +00:22:33.440 --> 00:22:35.440 + - Yeah. + +00:22:58.960 --> 00:23:02.640 + - I'm hungry. Did I get writing and recording this? So I + +00:23:02.640 --> 00:23:06.560 + actually did a month ago. So like, + +00:23:06.560 --> 00:23:10.530 + I don't even, I hardly even remember what it was, what that + +00:23:10.530 --> 00:23:12.160 + time was like, but yes, it's, + +00:23:12.160 --> 00:23:14.480 + it took a long time. These things, you know, these + +00:23:14.480 --> 00:23:16.480 + recordings are a little bit challenging. And in + +00:23:16.480 --> 00:23:18.780 + fact, I only kind of screwed up in several instances of the + +00:23:18.780 --> 00:23:20.240 + recording. And like, I just, + +00:23:20.240 --> 00:23:22.240 + I just don't have energy to kind of keep redoing. It's like + +00:23:22.240 --> 00:23:23.760 +, it's a long recording. It's also, + +00:23:23.760 --> 00:23:26.000 + I think I chopped it up into three bits. I'm not sure if it + +00:23:26.000 --> 00:23:27.600 + was that, is that obvious, but like, + +00:23:27.600 --> 00:23:31.860 + I guess, notes for people doing future sessions, it's like, + +00:23:31.860 --> 00:23:35.680 + make sure you have natural pauses that + +00:23:35.680 --> 00:23:39.860 + you can sort of just like record a segment because + +00:23:39.860 --> 00:23:42.880 + something would inevitably go wrong. And then like, + +00:23:42.880 --> 00:23:45.200 + if you're trying to repeat a 20 minute talk, it just takes + +00:23:45.200 --> 00:23:48.720 + forever. Yes. Oh yeah. The recipes. + +00:23:48.720 --> 00:23:54.230 + That's right. Yeah. I, well, yes, I'm glad you enjoyed the + +00:23:54.230 --> 00:23:56.480 + recipe. This is great. You put the + +00:23:56.480 --> 00:23:59.800 + recipes in there. Like one thing that I think is, is useful + +00:23:59.800 --> 00:24:01.840 + for, you know, regardless of what + +00:24:01.840 --> 00:24:06.110 + thing you're using in org-roam or EKG or whatever, you know + +00:24:06.110 --> 00:24:08.240 +, when you're making a recipe, + +00:24:08.240 --> 00:24:11.230 + you know, record in your daily diary, like, you know, when + +00:24:11.230 --> 00:24:12.800 + you, what you did it, if it worked, + +00:24:12.800 --> 00:24:16.160 + like what, what, you know, what adjustments you had to make + +00:24:16.160 --> 00:24:17.760 +, how it turned out, how it could be + +00:24:17.760 --> 00:24:21.320 + better. Then like, if it's linked to the recipe, then you + +00:24:21.320 --> 00:24:23.040 + have a kind of a record of like, oh, + +00:24:23.040 --> 00:24:25.720 + these are, you know, not just the recipe, but like your + +00:24:25.720 --> 00:24:27.840 + experiences making the recipe. I think + +00:24:27.840 --> 00:24:32.140 + it's really powerful because then you can see how, you know + +00:24:32.140 --> 00:24:34.480 +, you can kind of refine, refine and + +00:24:34.480 --> 00:24:37.030 + refine. It's really hard to do this in other ways. Like if + +00:24:37.030 --> 00:24:38.640 + just, you're just using your memory, + +00:24:38.640 --> 00:24:40.730 + you're, you're kind of like, well, it's, I can't remember + +00:24:40.730 --> 00:24:42.000 + what I did the last time I made this + +00:24:42.000 --> 00:24:45.940 + recipe, but like, you know, it seems a little bit extreme, + +00:24:45.940 --> 00:24:48.240 + but I think it's quite useful to use + +00:24:48.240 --> 00:25:01.720 + these note-taking applications for this use case. Okay. I + +00:25:01.720 --> 00:25:03.440 + think the stream has moved on, but again, + +00:25:03.440 --> 00:25:05.620 + you're all welcome to stay here and continue to Q&A as long + +00:25:05.620 --> 00:25:06.720 + as there are any questions. + +00:25:06.720 --> 00:25:13.440 + Thank you for your moderation. + +00:25:15.120 --> 00:25:19.920 + Cheers. Happy to. Thanks for the great talk. + +00:25:21.200 --> 00:25:21.200 + + +00:25:21.200 --> 00:25:23.200 + [end of transcript] + +00:25:46.080 --> 00:25:49.120 + While I see if there's any more questions, I'm going to + +00:25:49.120 --> 00:25:50.320 + fill in, I think not, not all + +00:25:50.320 --> 00:25:52.710 + the replies are filled in. So I'm going to start filling in + +00:25:52.710 --> 00:25:53.200 + this, you know, + +00:25:53.200 --> 00:25:56.240 + the pad that's associated with this. + +00:25:56.400 --> 00:25:56.400 + + +00:25:56.400 --> 00:25:58.400 + [end of transcript] + +00:26:00.160 --> 00:26:00.160 + + +00:26:00.160 --> 00:26:00.560 + Okay. + +00:26:02.560 --> 00:26:02.560 + + +00:26:02.560 --> 00:26:04.560 + [end of transcript] + +00:26:04.560 --> 00:26:14.560 + Okay. + +00:26:16.560 --> 00:26:16.560 + + +00:26:16.560 --> 00:26:18.560 + [end of transcript] + +00:26:20.560 --> 00:26:20.560 + + +00:26:20.560 --> 00:26:20.560 + Okay. + +00:26:22.560 --> 00:26:22.560 + + +00:26:22.560 --> 00:26:22.560 + Okay. + +00:26:24.560 --> 00:26:24.560 + + +00:26:24.560 --> 00:26:24.560 + Okay. + +00:26:26.560 --> 00:26:26.560 + + +00:26:26.560 --> 00:26:26.560 + Okay. + +00:26:28.560 --> 00:26:28.560 + + +00:26:28.560 --> 00:26:28.560 + Okay. + +00:26:30.560 --> 00:26:30.560 + + +00:26:30.560 --> 00:26:30.560 + Okay. + +00:26:32.560 --> 00:26:32.560 + + +00:26:32.560 --> 00:26:32.560 + Okay. + +00:26:34.560 --> 00:26:34.560 + + +00:26:34.560 --> 00:26:34.560 + Okay. + +00:26:36.560 --> 00:26:36.560 + + +00:26:36.560 --> 00:26:36.560 + Okay. + +00:26:36.560 --> 00:26:46.560 + Okay. + +00:26:46.560 --> 00:26:56.560 + Okay. + +00:26:56.560 --> 00:27:06.560 + Okay. + +00:27:06.560 --> 00:27:16.560 + Okay. + +00:27:16.560 --> 00:27:26.560 + Okay. + +00:27:26.560 --> 00:27:36.560 + Okay. + +00:27:36.560 --> 00:27:46.560 + Okay. + +00:27:46.560 --> 00:27:56.560 + Okay. + +00:27:56.560 --> 00:28:06.560 + Okay. + +00:28:06.560 --> 00:28:16.560 + Okay. + +00:28:16.560 --> 00:28:26.560 + Okay. + +00:28:26.560 --> 00:28:36.560 + Okay. + +00:28:36.560 --> 00:28:46.560 + Okay. + +00:28:46.560 --> 00:28:56.560 + Okay. + +00:28:56.560 --> 00:29:06.560 + Okay. + +00:29:06.560 --> 00:29:16.560 + Okay. + +00:29:16.560 --> 00:29:26.560 + Okay. + +00:29:26.560 --> 00:29:36.560 + Okay. + +00:29:36.560 --> 00:29:46.560 + Okay. + +00:29:46.560 --> 00:29:56.560 + Okay. + +00:29:56.560 --> 00:30:06.560 + Okay. + +00:30:06.560 --> 00:30:16.560 + Okay. + +00:30:16.560 --> 00:30:26.560 + Okay. + +00:30:26.560 --> 00:30:30.560 + All right. I, there's no one here and I don't like any + +00:30:30.560 --> 00:30:35.360 + other questions. So I am going to log out. Thank you + +00:30:35.360 --> 00:30:36.560 + everyone for your questions. + +00:30:36.560 --> 00:30:38.560 + [end of transcript] + +00:30:40.560 --> 00:30:40.560 + + |