Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
115 lines (100 sloc) 4.53 KB
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
- 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:
- 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:
- Joins
- 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
- rake tasks:
- github, rubyforge gem publishing
- benchmarking reports on large tables
- 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})
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.