Show HN: CursusDB – A new scalable distributed document oriented database
github.com
github.com
I read the title as CursorDB, which would have made a nice DB name.
Also, part of the beauty of open source is not trying to conform or constantly compare your project to others. It’s awesome that such diversity exists in project communities and the cross-pollination of ideas resulting from it.
it doesn't really matter what you label those comparisons.
think of it like LLM optimization.
If a project was aiming to get wider adoption and traction/momentum then yes, I agree. It doesn’t seem that this is an immediate goal of this project though.
Document-oriented databases might be reluctant to accept the premise that tables are better for users
'cause "alt1 vs alt2 vs alt3" is what I'm searching
Here is a PR to fix it. Just a simple parseInt. https://github.com/cursusdb/cursusdb-web/pull/1
https://www.youtube.com/watch?v=n1t5Iexx4UY <-- Automatic Recovery, Backups, Replica Sync, Lost Reconnect Demonstration
I've put lot's of effort into the documentation and continuously try to perfect it! https://cursusdb.com/documentation
In the video I will deploy the final application to Cloud Run and keep it online for you all to play with. I will respond to this with the video!
Cheers
Of course there are many ways to skin a cat, this seems like a very odd choice for organizing a database codebase. Some of the methods like cluster.HandleClientConnection() are crazy long for loop + if/else + switch + goto!
I know that you've said this is just kind of in your best interests codebase, but if I was planning on making any sort of dependencies on this project, I'd probably shy away from it because it seems like unmanageable spaghetti.
It's not even 3,000 lines. That's not a lot of spaghetti.
cluster.HandleClientConnection looks like a standard network service event loop, except the code is inline instead of spread across cluster.HandleSyncData, .HandleDelete, etc.
The lack of tests though...
If I want to add a feature or change some code around to fix something (like, say, migrate from one giant file to a bunch of individual files), then I want some sort of assurance that I haven't broken anything. That's what tests give you.
If you have someone contributing to your project, who doesn't necessarily have the whole 3,000 lines in their head, then tests give them the ability to make those contributions safely, without breaking anything.
It is all about doing things as standard as possible. Lowest common denominator for every one looking at the code base. As soon as you start to do things strangely in code (like a big single file with no tests), then people start to curse you. "What were they thinking when they wrote this?!!#@#!@#". I try to avoid those situations.
Tests also help document "the why". They become a history for changes over time. I could start to fix something that seems like a bug or strange design decision and look at the tests and realize that things were done intentionally... and give me the "why" they were done that way.
I don't see the structure of any main method changing. I just want to add tests must be driven meaning.. With a client. You don't test this system like you do a module in GO. You don't just write one test for CountLog(). If I absolutely had to sure.
When you test the client>cluster>node(s). So you always do driven testing as a client or multiple clients.
These keywords are the crux of the issue. What you're expecting is that third parties can read your mind. You have the whole codebase floating in your head so you understand where things are at and how it is laid out. If I'm working with others, or expecting people to pick up my project and either use it or contribute to it, I generally try to make it as easily understood as possible. Common sense is to break the file into manageable sections.
Again, tons of ways to skin a cat... but this is a huge red flag, for me.
Again, so many ways to skin a cat... if you can convince other people to contribute to your project as it is, then I'm definitely worthy of ignoring. =)
In order to comprehend it, I'm going to have to parse the whole thing into memory and figure out what it does. Not impossible, but if I'm looking to just fix a specific bug or contribute a new feature, I'd much rather go to the specific file that feature/bug is in, parse a page or two of code on my screen and work from there. It is just how I work.
I'm sorry that you have to deal with something that sounds worse. If it was me, I'd spend a lot of extra-curricular time trying to clean up the mess. In return, that would help me get an even better sense of the code.
But what I've found is that the .qqueue works as expected. If I make thousands of update requests to one document and the power goes out the CursusDB node system persists all updates on startup. Pretty cool stuff.
Welcome CursusDB!
(Random thought: Someone should create an online list of all known databases, all known versions of those databases, Lines-Of-Code (LOC) counts, the language that the database was written in, and the OS'es that it is available on. Also, same thing but for database connectors/drivers/APIs written to interface to different languages -- show me those languages for each connector... Or, maybe combine these these ideas into a website which allows people to search for databases by OS support, LOC, language written in, languages connector/APIs support, etc., etc.
That is, search for a database based on any and all attributes relative to a database).
Anyway, welcome CursusDB!
Thank you by the way! Great to see enthusiasm for new database systems!
Also, excellent link!
The only exception I know of is FoundationDB, which was written pretty much test-first, and about which Kyle Kingsbury said that their tests are likely better :-)
Thank you for your response.
[1]: https://rqlite.io
Before we jump into what is encrypted, and what is not, what are the threat vectors we are actually concerned about?
With rqlite all traffic between the nodes can be encrypted, as can be the HTTP API. Yes, the data at rest is not, but there are many ways to protect that[1]. One way would be to use an encrypted file system, perhaps.
Encrypted data-at-rest is a valid request, but what use cases would it address?
I never liked the idea of having any database storing my data in a way which can be seen in plain sight regardless of permissions and so forth. Servers get broken into very often and protecting the data within the files is important to me.
I've created another tool called qenc that may help the at rest problem if someone has a problem with it. qenc.org
With a CursusDB node on signal or automatic backup the system will encrypt and compress block by block. Using ChaCha and DEFLATE just to put that out there, it's pretty cool stuff!