I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
Article doesn't tell me why it's better than git's subtree merge.
LumoSQL
71–80 of 90 posts
Re: LumoSQL
#72Earlier quoted context omitted.
"LumoSQL can swap back end key-value store engines in and out of SQLite." => "LumoSQL can swap SQLite backend, with Key-value store engines" === "LMDB is the most famous (but not the only) example of an alternative key-value store" => "We currently only support LMDB as an alternative KV store" === "and LumoSQL can combine dozes of versions of LMDB and SQLite source code like this:" => "LumoSQL will allow you to use d…
Why are you reposting these sentences with additional errrors inserted into them?
i was rephrasing , saying what i understood (thinking i was making it clearer)
you are suggesting, i misunderstood the original text , if that is true i blame the original of being obfuscated
Re: LumoSQL
#73Earlier quoted context omitted.
Why is that? Surely that leads to conversations with open source contributors like 'this fails the test suite, but I can't show you, please fix it'?
This isn't an issue as SQLite doesn't accept contributions because they don't want to risk someone submitting proprietary code and lying about its origin. I've never understood why other large open-source projects are just willing to accept contributions from anyone. What's the plan when someone copy-pastes code from some proprietary codebase and the rights holders finds it?
The same issue is present with the use of LLMs. Are you absolutely sure it didn't just repeat some copyrighted code at you?
Re: LumoSQL
#74I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
Don't we just call these out-of-tree patches? Lots of those for Linux lying about, it's not a new idea. I guess the difference is that they have multiple upstreams, so really they're more of a new project that consists of:
- A set of sqlite patches,
- Other upstreams and patches?
- A custom toolchain to build all the above together into one artefact
Re: LumoSQL
#75Possibly the wrong place to ask this, but: I've played with SQLite when it was still available in-browser, and I felt that was on the brink of being a game-changer. If it was still supported in-browser and we had replication from the browser, peer-to-peer, I think we'd be living in a much more useful world. It's a lovely tech, but I never built anything serious around it. At this point, as a front-end web technology…
Chances are you have an installation or several running in your pocket right now. It's one of the most widely deployed pieces of software in existence. It's not supposed to be a 'traditional' DB in that running a webapp for many users sense (although it can do that), but to back client based software that need a data store/query tool and don't want to implement their own.
Agree with all of this. Also want to add that SQLite is a perfect jumping off point for full stack web-devs doing react-native (or similar) and want a familiar data query pattern they were already used to from MySQL, Postgres, etc.
Having a consistency of SQL everywhere is really appealing for data management.
Re: LumoSQL
#76I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
Don't we just call these out-of-tree patches? Lots of those for Linux lying about, it's not a new idea. I guess the difference is that they have multiple upstreams, so really they're more of a new project that consists of: - A set of sqlite patches, - Other upstreams and patches? - A custom toolchain to build all the above together into one artefact
If a trunk is a series of patches then isn’t maintaining a series of patches against multiple upstreams just maintaining multiple forks? Feels like mostly semantics to try to differentiate at this point. I mean what is the thing that you would get from doing it this other way? Isn’t it fundamentally still going to require pulling upstream changes regularly and resolving conflicts when they occur? Reading the treatise they say “this allows us to address conflicts that normally you would have to resolve manually”. So Git has tools to pick and choose and auto resolve conflicts, you just have to customize the behavior of your tooling a bit.
Seems like they’re just ditching the inbuilt tools git/github offers to achieve this and doing the exact same thing with custom bespoke tooling. Instead of doing that, I’d be more interested in leveraging what Git has baked in with some sort of wrapper tool to perform my automation with some bespoke algorithm. There are merge drivers and strategies end users can implement themselves for this kind of power user behavior that don’t require some weird reinvention of concepts already built into Git
Re: LumoSQL
#77Earlier quoted context omitted.
Yes. It's a small DSL to fork a repository and apply a series of textfile transformations (replace file, replace partial file). But if you give this a cool name, it's a New Idea.
So it's a fork but with somewhat semantic diff specifications?
Yes, specifications which could almost certainly be applied with a custom merge drivers or strategy rather than trying to come up with a clever name and hand baking a custom toolchain to do what you can already do with Git
Re: LumoSQL
#78Earlier quoted context omitted.
So it's a fork but with somewhat semantic diff specifications?
Yes, specifications which could almost certainly be applied with a custom merge drivers or strategy rather than trying to come up with a clever name and hand baking a custom toolchain to do what you can already do with Git
Not all projects use git.
Re: LumoSQL
#79I'd try it just for the LMDB mixing
I'd try it to see if it can be made to work against rocksdb or foundationdb - mvsqlite kind of does that but foundationdb is missing things like compression that rocksdb provides.
Re: LumoSQL
#80Earlier quoted context omitted.
Why is that? Surely that leads to conversations with open source contributors like 'this fails the test suite, but I can't show you, please fix it'?
This isn't an issue as SQLite doesn't accept contributions because they don't want to risk someone submitting proprietary code and lying about its origin. I've never understood why other large open-source projects are just willing to accept contributions from anyone. What's the plan when someone copy-pastes code from some proprietary codebase and the rights holders finds it?
Partly why they have CLAs I suppose?
If someone sells me something they stole, I'm not on the hook for the theft.