Og and DAO

Kashia answered:

UPDATE [2006-11-15]

This question is now marked as answered by the authorities due to unresponsive questioner.

The right place to look on how to implement a new store and adapter are following files and directories:

adapter/
store/
store.rb
entity.rb

To the distinction about store and adapter: A store is a general abstraction on how a certain type of stores react. All stores have to implement the interface of store.rb to be generally compatible. An adapter is a implemented store.

The only store right now is the sql store, it implements basic DB-independent SQL interaction. postgresql.rb, mysql.rb and sqlite.rb in the adapter/ folder all inherit from that SqlStore.

To add another store which is not compatible to SQL, one best writes first a new store, which implements basic behaviour of this specific type of backend.

To take the example of a RCS:

adapter/darcs.rb
adapter/svn.rb
adapter/arch.rb
store/rcs.rb

class RCSStore < Store
  
end
class DarcsAdapter < RCSStore
  
end

There is a litte problem right now though. the Entity specified in entity.rb is too SQL-aware. When implementing a different kind of store, this will probably lead to problems. These sql-aware functions should and will be abstracted away later (possibly) to store/sql/entity.rb.

Now to the question if it's meaningful.

I think that a LDAP adapter would be very nice. Address databases are quite often implemented in LDAP and I'm sure other uses can be found. LDAP basically works like a sql database, you can create, read, update and delete. With other things like revision control systems the question is a little harder I think. RCS' are there to keep a history of file-based (or patch based like in darcs) transactions. At the moment I can't get an image in my head on how this would 'react' as an Og Entity. In Og 0.31 and before there is a file store. A RCS could be used to track the history of those files, but I'm really not sure on the benefits of doing that and what the "Object" in this system would be. In darcs one could refer to patches as Objects, but while they can be created, read and deleted, they can not be updated.

I would say that any storage system which is has the possibility to create, read, update and delete a set of related keys/values can be used as a backend for Og.