1 files changed, 0 insertions, 125 deletions
diff --git a/sqlplain/doc/first-page.txt b/sqlplain/doc/first-page.txt
deleted file mode 100644
index 19f9521..0000000
--- a/sqlplain/doc/first-page.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-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.
-
-
-
-