Litedb: [QUESTION] Is LiteDB abandoned?

Created on 19 Dec 2020  路  7Comments  路  Source: mbdavid/LiteDB

Hi @mbdavid,
There is a lot of unclosed PRs waiting for the commit, even since 2017. Some of them, according to their description, are fixes of the bugs.
Is LiteDB abandoned?

question

Most helpful comment

I've already done this before with the FluentMigrator project. I took over from the previous maintainer, created an ORG, moved the project, configured build servers, added a documentation project, made several changes/upgrades to the tooling, sorted out the open issues/PRs, categorizing them, made several releases and - after a burnout - searched for a new maintainer, which keeps the project alive and kicking It was months of work, but it was totally worth it. A great project that I still personally use.

Some random thoughts about areas where the project could be improved:

  • BSON support in the same spirit like the new System.Text.Json, with Span<byte> which avoids most of the allocations
  • Complex index support

    • Multi-field indexes

    • Computed indexes (LiteDB has these, but the API seems limited)

  • Better documentation

    • Query.All(), how to use it, what's a common use case, etc...

  • Make the EXPLAIN functionality easily accessible for all query syntaxes

    • Documentation of the EXPLAIN result

  • Improve SQL syntax

    • There seems to be a difference between INCLUDE in SQL and Include in the internal query API. The former seems to be done used after the WHERE, while the latter is applied before evaluating the conditions in the Where()

  • Document-level security
  • Batching document changes (i.e. create/delete/update in a single "transaction", across collections)
  • Secure indexes (https://crypto.stackexchange.com/questions/3446/is-it-possible-to-match-encrypted-documents-using-user-defined-search-terms)
  • Use of "standard" libraries

    • Usage of a standard logging framework? (Microsoft.Extensions.Logging)

  • Refactoring into multiple separate projects

    • Make BSON available separately

    • Meke the persistence engine available separately

    • Separating the query- and index functionality too?

    • Combine everything together in the LiteDB main project

BUT the new co-maintainer/maintainer should of course first talk to the original maintainers about their ideas where the project could be improved and their opinions about the topics above.

TBH: I'm not a pro when it comes to DB engines and the theoretical background, so I'd most likely just be able to do janitorial work, but maybe there are some other experienced developers that know the risks of changes, and keep an eye on backwards compatibility (binary, API, storage).

All 7 comments

It surely seems that development slowed down, but several PRs were merged/closed during this year and after a look at the remaining ones, it seems that the open PRs are usually one of the following:

  • Unresolved questions around corner cases
  • Risky, because they might cause unforseen behavior (bugs)
  • Questionable usability
  • Abandoned PRs

Other than that, I guess that @lbnascimento does currently most of the work, while @mbdavid is only active sporadically. And most likely consider the project being mature.

However, it might make sense to create a separate ORG for LiteDB in case a maintainer change is desired or co-maintainers are searched.

@fubar-coder yah, I think it will better if All LiteDB Repositories moved to its organization account,

@ruslanmogilevskiy [@lbnascimento, @mbdavid] and other developers do extremely efforts to make this library, solve tones of issues,

But everyone has his personal life and problems, and LiteDB does not have any sponsorship, so you must consider that, if you find any issue, you think you can solve it, try to solve it, and try to help people here, either by fixing bugs if you can do that or by answering questions.

and @mbdavid: I think you should open the sponsorship, Also Do you ever think about https://github.com/sindresorhus/ama/issues/109

I hope you are in good health, but we must consider everything, so please think about moving the LITE-DB to a new Organization Account.

I've already done this before with the FluentMigrator project. I took over from the previous maintainer, created an ORG, moved the project, configured build servers, added a documentation project, made several changes/upgrades to the tooling, sorted out the open issues/PRs, categorizing them, made several releases and - after a burnout - searched for a new maintainer, which keeps the project alive and kicking It was months of work, but it was totally worth it. A great project that I still personally use.

Some random thoughts about areas where the project could be improved:

  • BSON support in the same spirit like the new System.Text.Json, with Span<byte> which avoids most of the allocations
  • Complex index support

    • Multi-field indexes

    • Computed indexes (LiteDB has these, but the API seems limited)

  • Better documentation

    • Query.All(), how to use it, what's a common use case, etc...

  • Make the EXPLAIN functionality easily accessible for all query syntaxes

    • Documentation of the EXPLAIN result

  • Improve SQL syntax

    • There seems to be a difference between INCLUDE in SQL and Include in the internal query API. The former seems to be done used after the WHERE, while the latter is applied before evaluating the conditions in the Where()

  • Document-level security
  • Batching document changes (i.e. create/delete/update in a single "transaction", across collections)
  • Secure indexes (https://crypto.stackexchange.com/questions/3446/is-it-possible-to-match-encrypted-documents-using-user-defined-search-terms)
  • Use of "standard" libraries

    • Usage of a standard logging framework? (Microsoft.Extensions.Logging)

  • Refactoring into multiple separate projects

    • Make BSON available separately

    • Meke the persistence engine available separately

    • Separating the query- and index functionality too?

    • Combine everything together in the LiteDB main project

BUT the new co-maintainer/maintainer should of course first talk to the original maintainers about their ideas where the project could be improved and their opinions about the topics above.

TBH: I'm not a pro when it comes to DB engines and the theoretical background, so I'd most likely just be able to do janitorial work, but maybe there are some other experienced developers that know the risks of changes, and keep an eye on backwards compatibility (binary, API, storage).

@fubar-coder i think @mbdavid should pay attention for your suggestion, we still wait him.

@fubar-coder also, LiteDB Studio should be improved even to cross-platform,

but I think , @mbdavid does not have any time, now, because I implemented The Recent List and The Core For Application Settings
And it merged to the main Branch https://github.com/mbdavid/LiteDB.Studio/pull/33 but it does not appear in the readme file of the repository, or in releases, although it exists in the code, and if you notice from that pull request, there is a long response time

So I think, @mbdavid and @lbnascimento, does not have much free time for this project

@AlBannaTechno , I personally and everyone here (hope so) do appreciate the @mbdavid and @lbnascimento work over this project. Ive started to use it recently and its cool. Just noticed that there`re a lot of unclosed PRs that is a sign of a problem (no time to continue, no interest, etc.). Hope the project will continue to live and evolve.

@ruslanmogilevskiy I highly respect the work that was done on this project. We'll see if s/o reponds here in January (after the holidays) and currently, there is no need to hurry things, as the points above just were some suggestions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

darcome picture darcome  路  3Comments

furesoft picture furesoft  路  4Comments

RealBlazeIt picture RealBlazeIt  路  3Comments

kuiperzone picture kuiperzone  路  4Comments

dangershony picture dangershony  路  3Comments