TODO

High Priority
===============
- fix the datastore to store column information with create table.
  make sure column names are ordered.  Need ordering info for consistent
  output in shell
- Fix any pending specs.
- Get rcov back up to 100%
- Fix INSERT to insert to datastore with known table name
- UPDATE
- allow proper quoting of table names
- SELECT column_name FROM table_name
- SELECT table_name.column_name
- SELECT * FROM table_name.column_name

Medium Priority
================
- DELETE (3 forms, see: http://dev.mysql.com/doc/refman/5.0/en/delete.html)
  - second form
  - third form
- Beef up primary key support.  We'll need to talk to the database
  at initialization to find the primary key, and whether or not
  it's an auto-incrememnt field.  For now, assume the primary key
  is named "id", and the auto-incrememnt is set to true
- Write all database access to a log (optional)
- LIMIT regression

Low Priority:
=============

- SELECT:
    - Joins
    - GROUP BY
    - OFFSET clause
    - LIMIT with offset clause
    - mysql procedures (for GROUP BY )
    - mysql modifiers  (i.e. DISTINCT)
    - subqueries.  Can we rewrite them as joins dynamically?
- Transactions: Serious transaction processing
- Other SHOW TABLES conditions
- Remove overriding of require.  Replace it with something which will
  autoload treetop file if in ruby, else require it with Treetop.load
- Move all parser transformations into seperate files (which will decouple
  the parser from the IR)
- other CREATE TABLE clauses
- Query timing
- CREATE TABLE - other clauses, other types
- utf-8.  Other char encodings?
- get it running on ruby 1.9

Miscelaneous:
===============

- rake tasks:
    - github, rubyforge gem publishing
- benchmarking reports on large tables

Unclassified:
===============

- Efficiency issues: Indexes ?
- should we give a dup of hashes out of the cache?  Does AR modify 
  the values inside the hash of #select?
- Database formats.  Is one big array per table really a good format?
  - Should Set be used instead of Array?
- Other database adapters?  SQLite?  Decouple design
- Could we make this lazy, as opposed to eager?
  - seems that we could, if we could figure out that certain queries
    are subsets of other queries.  For instance:
        SELECT * FROM users WHERE user_name = "scott"
        SELECT * FROM users WHERE user_name = "scott" AND first_name = "Scott"
   Or, that queries could be combined:
        SELECT * FROM users WHERE first_name = "Scott"
        SELECT * FROM users WHERE last_name = "Taylor"
        SELECT * FROM users WHERE first_name = "Scott" AND last_name = "Taylor"
- DRb, so that multiple mongrels can all talk to the same cache
- Threading for the drb/data access
- Security: simple key value pairs of username, password,
  with all access to data.  Can we encrypt this over SSL
  (or another secure protocol) to get to the DRB process?

Other Thoughts:
==================

- Plugable storage engine. Getting something working now is more important
  than building something great which works in 10 years.  Should also
  show what the priorities are (for instance, joins may be very important,
  but currently they are low on the priority list)
      
      - Pure Ruby, shared memory.  Thread/state based.  Concurrency issues,
        big time.  How to stay in sync with the database?
      - Use erlang.  How to use shared memory in erlang?  Something needs
        to persist the data in memory...
      - Use a prebuilt tool in erlang.  Mensia has an in memory database.
        Can it be lightweight and do everything we need it to do?
      - Use time based cache (like memcached), but only in certain places:
            cache(:ttl => 25.minutes) do
               User.find(:all, :conditions => {:my => :conditions})
            end

        This would replace the connection adapters select query,
        but only for that query (just as it works with cache_fu).  The first
        time the query is run, select * from users is cached.  No new query is
        run on the users table (assuming queries are wrapped in cache declarations)
        for another 25 minutes.  (How should multiple cache calls against the same table
        with different ttls work?).  The cache declaration would not need to exist inside
        a descendent of ActiveRecord::Base - it could just as easily come in a controller
        or presenter

        The declaration could also be made global for the whole model - although then
        it would loose much of it's flexibility.
   
  There's no reason all of these are options, just like mysql has different
  storage engines.