From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28277 invoked from network); 11 Jan 2021 04:34:57 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2021 04:34:57 -0000 Received: from wopr.sciops.net ([216.126.196.60]) by 1ess; Sun Jan 10 23:07:23 -0500 2021 Received: (qmail 84049 invoked by uid 1001); 10 Jan 2021 20:07:14 -0800 Date: Sun, 10 Jan 2021 20:07:14 -0800 From: Kurt H Maier To: 9front@9front.org Message-ID: Mail-Followup-To: 9front@9front.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: secure lossless grid property strategy Subject: Re: [9front] SQL Reply-To: 9front@9front.org Precedence: bulk On Sun, Jan 10, 2021 at 07:20:27PM -0800, William Gunnells wrote: > Okay so plan9 does not have DB because...well it's a file based > system. Okay okay so how would you manage large data. grep would suck. > I guess sqlite would work but is that even ported. I read somewhere > about using: https://github.com/harelba/q/ I don't know about that. I > don't have a practical use as of yet. Just curious. It seems like a > challenge to build some sort of http server in plan9 with basic > webauth capability and store data in a file. What's the file size > limitation? 9front has a list server. I'm sure that data is pretty > extensive but those pages are not being served. Thoughts? Plan 9 has databases. One example is ndb. Another is kenji's desktop search system, kirara. Your question conflates the concept of a database with the access mechanism. SQL is a query language. The reason it's not got much traction on Plan 9 is that most SQL engines are closely tuned to their host environment in order to stanch the bleeding on the traumatic performance hit taken when you wind up using a data access language that doesn't map well to the actual storage primitives your operating system provides. ndb declares relationships in terms of tuples, which are just collections of key-value pairs. Kirara works more like an indexing system that stores points from a given string to the file that contains it. Neither of these approaches require the massive amount of effort that would be required to write a performant SQL engine that doesn't corrupt your data along the way. On Plan 9, people tend to think about what data they're trying to access, and create data structures that make it easy to do the task your program is trying to accomplish. I don't know why you think making a web server would be such a challenge, since eekee has provided a pretty good one written in shell script (rc-httpd). It includes HTTP Basic Auth, but works just as well without it (for example, werc can handle its own user authentication). I suppose the inevitable question is "what exactly are you trying to accomplish?" If the answer is "I'm not sure yet," then SQL in front of a relational database might seem like a good idea. But there's nothing innate about tables and rows that can't be done with regular files and indexes and shit. In fact, that's what the RDBMSes are doing behind the scenes anyway, unless they're backed by object storage, in which case they've delegated to the object store. At some point, on systems like Unix and Plan 9, you have to open/read/write/close just like everyone else. You just have to decide how tall you want to build your sandcastle of abstractions in the process. khM