mirror of
https://github.com/golang/go
synced 2024-11-20 10:54:49 -07:00
c007ce824d
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.
47 lines
2.1 KiB
Plaintext
47 lines
2.1 KiB
Plaintext
Goals of the sql and sql/driver packages:
|
|
|
|
* Provide a generic database API for a variety of SQL or SQL-like
|
|
databases. There currently exist Go libraries for SQLite, MySQL,
|
|
and Postgres, but all with a very different feel, and often
|
|
a non-Go-like feel.
|
|
|
|
* Feel like Go.
|
|
|
|
* Care mostly about the common cases. Common SQL should be portable.
|
|
SQL edge cases or db-specific extensions can be detected and
|
|
conditionally used by the application. It is a non-goal to care
|
|
about every particular db's extension or quirk.
|
|
|
|
* Separate out the basic implementation of a database driver
|
|
(implementing the sql/driver interfaces) vs the implementation
|
|
of all the user-level types and convenience methods.
|
|
In a nutshell:
|
|
|
|
User Code ---> sql package (concrete types) ---> sql/driver (interfaces)
|
|
Database Driver -> sql (to register) + sql/driver (implement interfaces)
|
|
|
|
* Make type casting/conversions consistent between all drivers. To
|
|
achieve this, most of the conversions are done in the sql package,
|
|
not in each driver. The drivers then only have to deal with a
|
|
smaller set of types.
|
|
|
|
* Be flexible with type conversions, but be paranoid about silent
|
|
truncation or other loss of precision.
|
|
|
|
* Handle concurrency well. Users shouldn't need to care about the
|
|
database's per-connection thread safety issues (or lack thereof),
|
|
and shouldn't have to maintain their own free pools of connections.
|
|
The 'db' package should deal with that bookkeeping as needed. Given
|
|
an *sql.DB, it should be possible to share that instance between
|
|
multiple goroutines, without any extra synchronization.
|
|
|
|
* Push complexity, where necessary, down into the sql+driver packages,
|
|
rather than exposing it to users. Said otherwise, the sql package
|
|
should expose an ideal database that's not finnicky about how it's
|
|
accessed, even if that's not true.
|
|
|
|
* Provide optional interfaces in sql/driver for drivers to implement
|
|
for special cases or fastpaths. But the only party that knows about
|
|
those is the sql package. To user code, some stuff just might start
|
|
working or start working slightly faster.
|