Unified database interface

[Avey777]

Describe the feature

Currently, the database interfaces (mysql, pgsql, sqlite) lack a consistent abstraction layer. This results in:

Inconsistent Function Signatures: Similar operations (e.g., select, insert, update) have different method names, parameters, or return types across different database drivers.

Code Duplication & Complexity: Application logic dealing with multiple databases requires significant conditional branching and adapter code specific to each driver.

Hindered Development: Implementing features or fixing bugs that involve database access becomes cumbersome and error-prone when needing to handle each driver separately.

Reduced Maintainability: Changes or additions to database interaction logic must be replicated across multiple, subtly different implementations.

Proposed Solution:
Introduce a common, unified public interface (pub interface Connection) that abstracts the core database operations. Concrete driver implementations (mysql, pgsql, sqlite) will adhere to this interface, hiding their specific dialects and quirks behind it.

Benefits:

Consistency: Provides a single, predictable way to interact with any supported database from the application layer.

Simplified Application Logic: Eliminates the need for driver-specific conditionals in core application code. Developers work against the Connection interface.

Improved Maintainability: Changes to the core database interaction pattern (e.g., adding a new method, changing a signature) are made in one place (the interface and its common implementations). Driver-specific details are encapsulated.

Enhanced Testability: Mocking the Connection interface becomes straightforward for unit testing application logic independent of the actual database.

Easier Driver Development/Integration: Adding support for a new database type primarily involves implementing the well-defined Connection interface.

Unify the database interface, providing a good foundation for the implementation of https://github.com/golang/go/tree/master/src/database/sql

Use Case

not applicable

Proposed Solution

No response

Other Information

If possible, would you accept a complete reconstruction of the db library?

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Version used

V 0.4.11 4a44fc5

Environment details (OS name and version, etc.)

V full version	V 0.4.11 b9e5757.4a44fc5
OS	linux, Deepin 25
Processor	6 cpus, 64bit, little endian, Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
Memory	0.46GB/7.61GB
V executable	/home/Jengro/.vmr/versions/v_versions/v_latest/v
V last modified time	2025-07-01 09:32:46
V home dir	OK, value: /home/Jengro/.vmr/versions/v_versions/v_latest
VMODULES	OK, value: /home/Jengro/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/Jengro/Documents/Dev/v-product/vprod-workspase/backend/internal/middleware/dbpool
Git version	git version 2.47.2
V git status	weekly.2025.26-33-g4a44fc5a
.git/config present	true
cc version	cc (Deepin 12.3.0-17deepin14) 12.3.0
gcc version	gcc (Deepin 12.3.0-17deepin14) 12.3.0
clang version	N/A
tcc version	tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
tcc git status	N/A
emcc version	N/A
glibc version	ldd (Debian GLIBC 2.38-6deepin13+rb1) 2.38

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github[bot]]

Connected to Huly®: V_0.6-23279

[Avey777]

@medvednikov
What do you think about this

[JalonSolov]

I am not against this idea - I think a consistent interface across all databases would make it simpler for everyone who uses them... they could test which database works best for their application without changing much of their code.

However, this puts a larger burden on V developers, who now have to become familiar with every database in order to add a new feature to any of the drivers, since it will have to be added to all of them.

This can lead to those new features simply not being added, because the person who wants to add it for one of them has no interest in figuring out what needs to be done to make the others work.

In a corporation with hired employees, they can be told to do this. In a open source project, they have to want to do this, or it won't get done.

[jorgeluismireles]

The database concept is not exclusively SQL. For instance we have already db.redis and maybe others could be added, like Mongo and more. So trying to build an abstraction layer which succeeds is a difficult and time consuming topic. By the way this topic should be a discussion not an issue to solve.

[jorgeluismireles]

For SQL exclusively isn't V's ORM such abstraction layer?

[Avey777]

For SQL exclusively isn't V's ORM such abstraction layer?

The driver layer and SQL layer are different

[jorgeluismireles]

@Avey777: You provide a link about Golang module database/sql that it is SQL oriented. But there is another module database/sql/driver, is concepts there what are you talking about here? Seems to me that from the point of V's clients, driver's topics are are things related to HTTP connections, timeouts, re-connections... common to both SQL and No-SLQ such as PG, Maria, Redis, Mongo... but not too much important for Sqlite. By the other hand, we are working also with topics such as transactions' commits and rollbacks that maybe your are also thinking about?