[HN Gopher] LumoSQL
___________________________________________________________________
LumoSQL
Author : tosh
Score : 36 points
Date : 2022-04-03 10:38 UTC (2 days ago)
(HTM) web link (lumosql.org)
(TXT) w3m dump (lumosql.org)
| sam_goody wrote:
| Why the no-fork and not a branch?
|
| Just maintain a dev branch on SQLite, the same as on, say, NGINX,
| and only merge into mainline after > 3 years of use by the lots
| of users that are safe using dev.
|
| Will get it battle tested better and fatser, and in the hands of
| far more users. Why have a not-a-fork fork?
| a3w wrote:
| The "not forking" graphics look a lot more like forks then spoons
| or knives. Let's call that forking. Or if they insist on renaming
| monkey patching to something new: lets name it pitchforking or
| tridenting.
| quietbritishjim wrote:
| If you're going to be pendantic about terminology: monkey
| patching is patching at runtime in a dynamic language like Ruby
| or Python.
| Sytten wrote:
| Does someone have results for the benchmarks comparing the
| different backends, they say that it brings improvements but no
| numbers.
| Jason_Gibson wrote:
| This forum post has some info on benchmarking SQLite with two
| different backends:
|
| https://sqlite.org/forum/forumpost/9aa5e1dcffde1336
|
| See the "preliminary results" link.
| [deleted]
| zcw100 wrote:
| What library do you plan on using for the attribute based
| encryption?
| flakiness wrote:
| SQLite has a pluggable table API (virtual table).
|
| I thought it was sufficient to implement a different backend, but
| apparently that's not the case. I hope the direction they push is
| to extend the vtable API to make it capable of their use case.
| KwisaksHaderach wrote:
| Aside, anyone used the java sqlite driver
| https://github.com/xerial/sqlite-jdbc in production (webapp with
| multiple users)? Has the driver been reliable?
| giaour wrote:
| Yes and yes, though I used it for a read-only application.
| arghwhat wrote:
| > LumoSQL is a modification (not a fork) of the SQLite embedded
| data storage library
|
| So it modifies SQLite to add various features, thus deviating
| from SQLite as it is while still using it as its base? That's
| what a fork is.
| warp wrote:
| A fork implies that the projects are going diverge, which it
| seems they don't want to happen.
|
| From a quick reading of that page I think the LumoSQL authors
| are making the effort to maintain their set of modifications as
| some kind of patch which will continue to be compatible with
| future SQLite versions as they are released.
| mbreese wrote:
| Maybe it would be better referred to as a "tracking fork". At
| least, that's how I'd think about it.
| miohtama wrote:
| Historically these are called patches or patchsets.
| skissane wrote:
| SQLite is public domain, LumoSQL is MIT-licensed.
|
| If they want to stay as close as possible to upstream, you'd
| think they'd either keep it public domain, or else choose a
| public domain-equivalent license (such as MIT-0, 0BSD, CC0,
| etc).
| fivea wrote:
| > A fork implies that the projects are going diverge,
|
| ...which is exactly what you're doing when you branch off a
| release branch and start applying your own commits with no
| plan to merge them back to mainline.
|
| > which it seems they don't want to happen.
|
| They are already doing it. They are only arguing that they
| can reapply the same patches over the next release branch,
| but that doesn't really change anything.
| [deleted]
___________________________________________________________________
(page generated 2022-04-05 23:02 UTC)