Removed ~ files added by mistake

8 files changed, 0 insertions, 376 deletions

diff --git a/sqlplain/doc/book_importer.py~ b/sqlplain/doc/book_importer.py~
deleted file mode 100644
index 1398cbe..0000000
--- a/sqlplain/doc/book_importer.py~
+++ /dev/null
@@ -1,37 +0,0 @@
-import re, csv, itertools
-from sqlplain.namedtuple import namedtuple
-
-Book = namedtuple('title author genre nation date')
-
-BOOKFILE = re.compile('books(\d\d)')
-
-class BookImporter(object):
-    def __init__(self, db):
-        self.db = db
-        self.bookid = KTable.reflect(db, 'bookid')
-        self.book = KTable.reflect(db, 'book')
-        self.counter = itertools.count(1)
-
-    def import_year(self, books, year):
-        for b in books:
-            self.bookid.insert_row(
-                id = self.counter.next(),
-                title = b.title,
-                author = b.author,
-                rdate = b.date)
-
-    def import_all(self, dirname):
-        n = 0
-        for fname in os.listdir(dirname):
-            mo = BOOKFILE.match(fname)
-            f = file(os.path.join(dirname, fname))
-            if mo:
-                yy = int(mo.group(1))
-                if yy > 80:
-                    year = 1900 + yy
-                else:
-                    year = 2000 + y
-                rows = map(Book, csv.reader(f))
-                f.close()
-                self.import_year(rows, year)
-
diff --git a/sqlplain/doc/books1.sql~ b/sqlplain/doc/books1.sql~
deleted file mode 100644
index 1320689..0000000
--- a/sqlplain/doc/books1.sql~
+++ /dev/null
@@ -1,32 +0,0 @@
-CREATE TABLE bookid (
- id INTEGER AUTO_INCREMENT PRIMARY KEY,
- title VARCHAR(128),
- author VARCHAR(64),
- rdate DATETIME,
- UNIQUE (title, author rdate));
-
-CREATE TABLE score (
- score VARCHAR(4) PRIMARY KEY,
- value INTEGER);
-
-CREATE TABLE genre (
-  id CHAR(2) PRIMARY KEY,
-  descr VARCHAR(32))
-
-CREATE TABLE nation (
- id CHAR(2) PRIMARY KEY,
- descr VARCHAR(32));
-
-CREATE TABLE book (
- id INTEGER PRIMARY KEY REFERENCES bookid (id),
- genre CHAR(2) REFERENCES genre (id),
- nation CHAR(2) REFERENCES nation (id),
- score INTEGER REFERENCES score (value));
-
-CREATE VIEW book_view AS
- SELECT a.id, a.title, a.author, a.rdate, b.genre, b.nation, c.score 
- FROM bookid AS a
- INNER JOIN book AS b
- ON a.id = b.id
- INNER JOIN score AS c
- ON c.value=b.score;
diff --git a/sqlplain/doc/cache_ex.py~ b/sqlplain/doc/cache_ex.py~
deleted file mode 100644
index f9b802b..0000000
--- a/sqlplain/doc/cache_ex.py~
+++ /dev/null
@@ -1,28 +0,0 @@
-from sqlplain.memoize import Memoize
-
-class Forever(object):
-    "Cache type for caches which are is never cleared"
-    
-class LongTime(object):
-    "Cache type for caches which are rarely cleared"
-    
-class ShortTime(object):
-    "Cache type for caches which are is often cleared"
-
-@Memoize(ShortTime)
-def f1():
-    return 1
-
-@Memoize(LongTime)
-def f2():
-    return 2
-
-@Memoize(Forever)
-def f3():
-    return 3
-
-def test1():
-    assert not f1.cache
-    f1()
-    assert f1.cache == {(): 1}
-    
diff --git a/sqlplain/doc/compare_tables.py~ b/sqlplain/doc/compare_tables.py~
deleted file mode 100644
index f714473..0000000
--- a/sqlplain/doc/compare_tables.py~
+++ /dev/null
@@ -1,32 +0,0 @@
-from sqlplain import lazyconnect
-from cStringIO import StringIO
-#from sqlplain.postgres_util import get_schema_postgres
-#print get_schema_postgres(rcare.uri, 'customer')
-
-rcare = lazyconnect('rcare')
-rcare_prod = lazyconnect('rcare_prod')
-
-CREATE_CUSTOMER = '''
-CREATE TABLE customer_prod (
-    client_id character varying(32) PRIMARY KEY,
-    description character varying,
-    email character varying,
-    short_description character varying(16),
-    mail_report_info character varying(128),
-    attach_prefix character varying(32),
-    filter_from character varying(32),
-    zope_id character varying(32),
-    lookup boolean,
-    client_srs character varying(32),
-    CONSTRAINT nnull_id_short_desc CHECK ((short_description IS NOT NULL))
-);
-'''
-
-def copy_from(src, dest, table):
-    out = StringIO()
-    src._curs.copy_to(out, 'customer')
-    if not exists_table(
-    dest.create_table('customer_prod', force=True)
-    dest._curs.copy_from(out, 'customer_prod')
-    out.close()
-
diff --git a/sqlplain/doc/first-page.txt~ b/sqlplain/doc/first-page.txt~
deleted file mode 100644
index 3e0fe47..0000000
--- a/sqlplain/doc/first-page.txt~
+++ /dev/null
@@ -1,138 +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.
-
-Differences with the DB API
---------------------------------------------------
-
-sqlplain has a functional feeling.
-i have always hated the DB API 2, particularly the fact that the execute
-method does not return anyything but works by side effects, changing
-the state of the cursor so that the next fetch operation returns the
-retrieved rows. In sqlplain instead the eexecute method returns
-directly the retried rows and there is no explicit concept of cursor.
-This is not a particularly original idea, and actually the sqlite
-driver offers the same functionality. The rows are returned as named
-tuples, not as raw tuples.
- 
-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.
-
-
-
-
diff --git a/sqlplain/doc/logtable.py~ b/sqlplain/doc/logtable.py~
deleted file mode 100644
index 50713a8..0000000
--- a/sqlplain/doc/logtable.py~
+++ /dev/null
@@ -1,12 +0,0 @@
-from sqlplain import do, lazyconnect, util
-
-create_log_table = do("""
-CREATE TABLE log(
-  date DATETIME,
-  message VARCHAR(255))
-""")
-
-if __name__ == '__main__':
-    db = lazyconnect('sqlite_test')
-    util.drop_table(db, 'log', force=True)
-    create_log_table(db)
diff --git a/sqlplain/doc/queries.py~ b/sqlplain/doc/queries.py~
deleted file mode 100644
index e3f0dd9..0000000
--- a/sqlplain/doc/queries.py~
+++ /dev/null
@@ -1,5 +0,0 @@
-from sqlplain import do
-
-get_authors = do('select author from book')
-get_titles = do('select title from book where author=?')
-set_uppercase_titles = do('UPDATE book SET title=upper(title)')
diff --git a/sqlplain/doc/tables.py~ b/sqlplain/doc/tables.py~
deleted file mode 100644
index 6f3f401..0000000
--- a/sqlplain/doc/tables.py~
+++ /dev/null
@@ -1,92 +0,0 @@
-"""                                    
-The table framework
-------------------------------------------------------------
-
-As I said in the introduction, ``sqlplain`` is not intended to be
-a fully fledged ORM, therefore it does not provide a builtin mechanism
-to map user defined classes to database objects, such as the mapping
-mechanism in SQLAlchemy, or the popular Active Record pattern; nevertheless,
-it provides a table framework which us a lightweight object oriented layer
-over database tables.
-``sqlplain`` table object comes in two flavors: D-tables, which should be
-used for tables without a primary key, and K-tables, which must
-used for tables with a primary key, possibly composite. Actually K-tables
-are D-tables too, since they inherit from D-tables, therefore they
-share all D-tables methods and they add a few methods which are
-meaninful only if the underlying table has a primary key.
-If you try to use a K-table over a database table which has no primary
-key, a ``TypeError`` will be raised. Here is an example:
-
-$$logtable
-
->>> from sqlplain import table
->>> import logtable
->>> db = logtable.init('sqlite_test')
->>> log = table.KTable.reflect(db, 'log')
-Traceback (most recent call last):
-  ...
-TypeError: table log has no primary key!
-
-Using a DTable instead works:
-
->>> log = table.DTable.reflect(db, 'log')
-
-The ``.reflect`` classmethod creates a suitable subclass of ``DTable``
-(called ``Log``) and instantiates it. ``DTable`` is a kind of abstract
-base class and you cannot instantiate it directly (the same is true
-for the KTable class):
-
->>> table.DTable(db)
-Traceback (most recent call last):
-  ...
-TypeError: You cannot instantiate the ABC DTable
-
-In order to create a concrete subclass of DTable (or KTable) one needs
-to set the tabletuple class attribute ``tt``, which contains information
-about the table structure. The ``.reflect`` method extracts the information
-from the database schema; for instance ``log.tt`` is a namedtuple with
-fields ``date`` and ``message``:
-
->>> print log.tt._fields
-('date', 'message')
-
-
->>> from datetime import datetime
->>> now = datetime.now
->>> log.insert_row(date=now(), message='message1')
-1
->>> log.insert_row(date=now(), message='message2')
-1
->>> print len(log)
-2
-
-Here is the full API for DTable:
-
-- type
-- create
-- reflect
-- select
-- count
-- delete
-- truncate
-- insert_row
-- insert_rows
-- insert_file
-
-Here are the additional methods of K-tables:
-    
-- select_row
-- update_row
-- update_or_insert_row
-- delete_row
-
-Instead of an explanation, I will give examples::
-
-    select_book = select_row('book', 'title author')
-    select_book(bookdb, title='T', author='A')
-
-``select_row`` raises an error if the corresponding queries
-returns no result (you are looking for a missing record) or
-if it returns multiple results (it means that your primary key specification
-was incomplete).
-"""