Skip to content

Question: Effort and places to support other databases #566

@surfmuggle

Description

@surfmuggle

In 2021 postgresql support (69) was suggested and it was decided to not support it. In 2022 support for LiteDB was added and in 2023 the DbProviders Logic was separated in a standalone project.

I wonder from a technical standpoint if the refactoring of the DbProviders has the positive effect that the effort to implement a Provider for PostgreSQL or SQLite / libsql-server is reduced?

I assume that RegisterDataLayer is the place to start looking. And that one would have to create an implementation for the IRepository and the IDatabaseContext Interface?

  • Are there other places / classes / interface to take care of?
  • Can this be done without huge effort or is there a fundamental clash of philosophies (plain-sql vs non-sql)?

Thanks

Edit
I just stumbled over YesSql.

YesSql is a .NET Core document database interface over relational databases which allows you to define documents and indexes using plain old CLR objects. The main difference with document databases is that it uses any RDBMS to store them, which gives you all the power of SQL databases like transactions, replication, reporting, ... But the main advantage might be that there is no magic involved, it's pure SQL!

I have never tried YesSql but wonder if used as a proxy between GrandNode2 Repository Layer and a relational database would make it easier to support relational databases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions