Since the first meeting about the Ruby Adapter for AvocadoDB, there was a lot of discussion about how we should implement it: Should it be a standalone project or a driver for an existing ORM/ODM? If it should be standalone, should it be a a fork of an existing project or an entirely new one? In this thread I want to discuss these questions.
I will start with describing the goals of the project as I see them:
If you want to build an ODM in the Ruby Community, it is very important that it integrates well with Rails and Sinatra, because those are the most important Web Frameworks in the community. This should be the most important goal for Ashikawa.
The other goal should be to leverage the flexibility that a Document Store provides in comparison to a relational database and allow to access the capabilities of AvocadoDB as a Key-Value-Store and Graph-Database.
When implementing AvocadoDB, I see the following options:
1. Implement it as a driver for DataMapper
2. Implement it as a driver for ActiveRecord
3. Implement it as a driver for Mongoid (if that is possible)
4. Implement it as a fork of Mongoid
5. Implement it from scratch
1 + 2:
In the Ruby Community there are a lot of people with strong opinions. Between the DataMapper and ActiveRecord Camp there are lot of discussions. Dan Kubb, the maintainer of DM (DataMapper), contacted Frank via Twitter. He pointed us to the high number of non-relational systems supported by DM. I found on their [Wiki](https://github.com/datamapper/dm-core/wiki/Adapters) that there is third-party support for MongoDB, Github (yep), Riak... and many, many more. I think that the [MongoDB adapter](https://github.com/solnic/dm-mongo-adapter/) is a good example for what is possible. But, as Dan said on Twitter: "It can work with document stores, but ones where the properties are known ahead of time." I have not further explored the possibilities of ActiveRecord in that regard, but I think it is the same there.
In my opinion that is a sacrifice of flexibility: A driver like that should not be the only option. But maybe it is a good idea to support it as one possibility. Why? Because we could provide developers using a framework like that to switch to AvocadoDB from another database with very little effort.
3+4:
Mongoid is an ODM for -- surprise, surprise -- MongoDB. If you look at their [Github Repos](https://github.com/mongoid) they seem to change some things right now. They created Origin, which is a DSL for building queries for MongoDB and Moped, which is a "MongoDB Driver for Ruby". In the current version I don't see an option to provide a different driver to Mongoid, but maybe Moped is the effort to allow that in the future.
5:
Implementing the functionality from scratch allows us to leverage the strength of AvocadoDB. The problem is that we would make it a higher effort for people to switch to AvocadoDB with an existing application and the effort to make it compatible with Rails and Sinatra (and the effort in general) would be higher for us.
Therefore I propose a modular system that consists of multiple gems. One should be the core that provides a wrapper around the REST interface of AvocadoDB that will be used by all other gems. I would suggest "ashikawa-core" as the name for this project. It should provide everything that the REST interface offers to the Ruby developers. Nothing more, nothing less. Don't provide a DSL to create queries here (because that may very between the "higher-level" gems), only the possibility to send a query to the database as a string.
We should also create a gem that creates AQL-queries with a nice DSL. I started this with [brazil](https://github.com/moonglum/brazil). The project is currently on hold, because AQL is currently redesigned. I will continue with the development as soon as "AQL 2" solidifies. This should also be usable by "higher-level" gems in my opinion as it is an equivalent to Arel (from ActiveRecord) and Origin (MongoDB).
I would love to hear what you think about this topic. I will start with ashikawa-core sometime very soon, because we will need something like that anyway. As soon as there is something to see in that area, I will of course inform this mailing list.
Best Wishes,
Lucas