1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
sqlplain: a simple and opinionated Databases Toolkit
====================================================================
sqlplain is a small Python library with the aim of simplifying your
interaction with relation databases.
sqlplain is very much opinionated and it
does not try to be everything to everybody. It is intended to be a
middle level toolkit: higher level than the DB API 2, but lower
level than SQLAlchemy.
It was written in part as a reaction to SQLAlchemy (only in part since I
wrote the core of sqlplain years ago, before the publication of SQLAlchemy).
SQLAlchemy is actually
an impressive piece of software but I think it is overkill for many users.
sqlplain is for users looking for a simple library. It is also fine for
database administrators with a lot of experience in SQL and little
experience in Python, since its basic mode of operation is just to run
plain old SQL scripts (hence the name).
Its design guidelines are the following:
- conciseness
sqlplain is committed to keep the codebase small (say under 2000 lines)
and the number of features limited;
- simplicity
sqlplain is based on a simple
implementation, to make it easy for its users to understand it and to
build the features they need;
- easyness of use
sqlplain has a small learning curve
and provides a small set of convenient utilities for scripting your
database interation;
- familiarity
sqlplain connections are a simplified version of standard
DB API 2 connections, and you can readily get the underlying low
level connection to use of all its power, if need there is;
- transparency
sqlplain tries hard not to add too many layers of indirection to your
SQL queries: the idea is that it should be easy for the user to extract
the plain old SQL query from the code, cut and paste it on the database
console, and try it out directly.
sqlplain can be used to do anything on a database, but there is special
support for the following areas:
- creating test databases
- running database performance tests
- introspecting pre-existing databases
- scripting database operations
- memoizing queries
You can use sqlplain with your Web framework of choice (I have
been running it with Pylons for years without problems) but there
is no special integration with any framework - this is an advantage
or a disadvantage depending on your point of view. Certainly sqlplain
is *not* intended to be used as the Django ORM. Django (as most
Python ORMs) puts the emphasis on Python, in the sense that the
model is written down as a set of Python classes which are then
persistent to the database. On the contrary, sqlplain assumes
that you already have your tables on the database and that they
are managed via DDL queries: you can introspect your tables
from Python, but if you want to look at their definitions you
must look into SQL code, not into Python code. There is no
facility to create tables from Python code (actually there is,
but it works by just passing plain SQL code to the creational procedure)
and no facility to modify the schema of an existing table from
Python (apart for passing raw "ALTER TABLE" queries to the connection
object).
sqlplain does provide limited support for the following areas:
- database independence
True database-independence is a dream, since the features and the
performance characteristics provided by different databases are
totally different. Therefore, sqlplain does not even attempt to
be a fully database-independent toolkit. However, in the cases where
I could keep database-independence with little effort, I kept it.
In particular the introspection functionalities are database-independent.
But in general I judge spending a lot of time to provide a false sensation
of database independence not worth the effort.
- programmatic generation of SQL queries
Some database toolkits (notably SQLAlchemy) have an incredibly sophisticated
mechanism to generate SQL queries from Python objects in a
database-independent way. That is not the goal of
sqlplain. Out of the box sqlplain provides no support at all for generating
SQL queries programmatically, however the documentation provides a few
do-it-yourself recipes.
- Object Relation Mapper
The core of sqlplain does not provide any ORM. A small table framework
is provided as an experimental extension: its goal is to provide a small
object oriented wrapper over the tables of database, but it is not an
ORM such as the ones you can find in SQLAlchemy, SQLObject or Storm.
It is pretty easy to write custom classes making use of the table
framework, but you are on your own, there is nothing built-in.
This is done on purpose.
- Connection pooling
sqlplain does not provide any connection pooling facility and it will never
provide one. There are already many connection pool implementations available
out there and just use the one you like, if you need one.
Notice that you can use sqlplain connections in a multithreaded application
(such as a Web server) even without an explicit connection pool since the
connections can be made thread local.
- no support for nested transactions, no unit-of-work pattern.
|
