71–80 of 82 posts
I don’t recommend writing a DB in Python. So much of DB development is dealing with race conditions and consistency.
Python files require an interpreter. Bad for a DB.
And dependency management is a pain. Are you thinking a virtualenv for this?
Earlier quoted context omitted.
> but with Python you'll never even know what the real thing is like What do you mean? Surely the concepts are similar regardless of using Python or C?
Not even close. The real problems you will have to solve when working with a database anyone would want to use are, for example: * Memory layout of the buffers used to write / read / cache this data. In Python, you don't even have a concept of memory alignment / layout -- it's all happening somewhere in the interpreter. * How to best service multiple requests concurrently. Again, Python offers nothing here, and nothi…
The experts are doing databases in C and C++ and Rust. But I'm not a C, Rust or C++ expert, so I need to start somewhere, where I am today.
I start small accomplishable goals to get the idea of the problem solution so I'm not distracted by boilerplate C, C++ or Rust. My multiversion concurrency control is in Java.
You might think all the things are easy but they're not easy to everyone. We have to start somewhere and one way to start is to write the parser in a simple language so you're not wrestling with memory management.
If I tried to do all the things you mentioned in C++, Rust or C it would be too much work in one step. I need to start small to have an achievable result.
Not everyone is Stonebraker or Linus Torvalds.
I know Python, but little C. I don’t recommend writing a DB in Python. So much of DB development is dealing with race conditions and consistency. Python files require an interpreter. Bad for a DB. And dependency management is a pain. Are you thinking a virtualenv for this?
> > What I Cannot Create, I Do Not Understand -Richard Feynman
> In the spirit of Feynman's immortal words, the goal of this project is to better understand the internals of databases by implementing a relational database management system (RDBMS) (sqlite clone) from scratch.
> This project was motivated by a desire to: 1) understand databases more deeply and 2) work on a fun project.
It sounds like they couldn't care less if it's production-ready.
Is this really a relational database if it does not have JOINs?
It does have joins
I dont see "JOIN" there.
So either the DB doesnt support it or the documentation (on the splash page!) is wrong.
Thanks for the downvote.
I know Python, but little C. I don’t recommend writing a DB in Python. So much of DB development is dealing with race conditions and consistency. Python files require an interpreter. Bad for a DB. And dependency management is a pain. Are you thinking a virtualenv for this?
The project is entitled LearnDB, and this is how they describe their motivation in the first two paragraphs of the README: > > What I Cannot Create, I Do Not Understand -Richard Feynman > In the spirit of Feynman's immortal words, the goal of this project is to better understand the internals of databases by implementing a relational database management system (RDBMS) (sqlite clone) from scratch. > This project was m…
Earlier quoted context omitted.
Not even close. The real problems you will have to solve when working with a database anyone would want to use are, for example: * Memory layout of the buffers used to write / read / cache this data. In Python, you don't even have a concept of memory alignment / layout -- it's all happening somewhere in the interpreter. * How to best service multiple requests concurrently. Again, Python offers nothing here, and nothi…
Guess to get back to the post. He did it for learning, not to be an exact duplicate or competitor to replace other RDBMS. Often when learning, you do not implement every difficult edge case, the most complex. You are just trying to get the jist of it. You want a smaller problem to solve. Maybe as a learning project, it isn't important to have concurrency, networking, memory management. Unless, any of those things hap…
Giving someone Python to make a database, is like giving a student in a culinary school a dull knife: it's hard to do it with the right tools, but it becomes mission impossible when you are also crippled by your tools.
It's the same analogy I used before: using toy "doctor set" vs. learning to be a surgeon. There's no path that will bring you from using a toy set to be a surgeon. It serves a different purpose: entertainment / roleplay. You don't mean to roleplay as a programmer by using Python, right?
Earlier quoted context omitted.
Yes. It's an interesting area, irrespective of implementation language. I had tried out one or two Java-based RDBMSes back in the day, via programs written in Java, for fun. I think one was HSQLDB. https://en.m.wikipedia.org/wiki/HSQLDB There was also another interesting one called PointBase, which was developed by Bruce Scott, an Oracle founder, and others. https://en.m.wikipedia.org/wiki/PointBase
H2 is pretty great and fully supports JSONB and the like [1]. Full java-only RDBMS. [1]: https://www.h2database.com/html/main.html
Earlier quoted context omitted.
It does have joins
The splash page says that Learndb supports the following: select, from, where, group by, having, limit, order by I dont see "JOIN" there. So either the DB doesnt support it or the documentation (on the splash page!) is wrong. Thanks for the downvote.
Please don't do this here.
Additionally, it could have been anyone.
Earlier quoted context omitted.
Guess to get back to the post. He did it for learning, not to be an exact duplicate or competitor to replace other RDBMS. Often when learning, you do not implement every difficult edge case, the most complex. You are just trying to get the jist of it. You want a smaller problem to solve. Maybe as a learning project, it isn't important to have concurrency, networking, memory management. Unless, any of those things hap…
Because, especially for learning, you need tools adequate for the task... Masters can be more flexible and use inferior tools and still be successful; students need every bit of help they can get, and they need the tools that aren't going to betray them every step of the way. Giving someone Python to make a database, is like giving a student in a culinary school a dull knife: it's hard to do it with the right tools,…
Earlier quoted context omitted.
This is a very early release, whereas SQLite has 22 years of releases. In that light, this is about the least charitable take on this. Someone in our community built something and had the courage to release it. Your criticism is unfair.
> Your criticism is unfair. I think it doesn't even get close to being a criticism, and it's certainly unclear if the goal is to literally clone SQLite or to implement SQLite-ish. This is a fair question.