couchdb + datamapper (2)

想來想去，用比較簡單的結構的話，就是一個 model 配一個 db.
比方說：

DataMapper.setup(:default, 'couchdb://localhost/test')

然後有 model Photo, Album, User 的話就是會建立三個 db,
test_photos, test_albums, test_users.

這樣做最大的理由是做 partition 會比較容易。
其次是先減少 database 的複雜度，因為想想覺得
如果要放在同一個 db 裡，relation 一多的話，
整個情況會變得非常複雜。先想簡單的，熟悉之後再看複雜的。

一決定這樣做之後，view 要怎麼設就很清楚了。
User.has n :photos
Photo.belongs_to :user
就是 test_photos 裡有個 view, 是：

emit(photo.user_id, photo)

雖然我不確定能不能直接把整個 doc 當成 value, 總之先這樣看。
因此寫：

User.get("id").photos 時會產生：

GET http://localhost/test_users/id
GET http://localhost/test_photos/_views/user_id?
startkey=id&reduce=false

reduce 的部份，當然就是 count, 也就是 values 的 size 了。
另一邊的查詢則不需要 view.

Photo.get("id").user 時會產生：

GET http://localhost/test_photos/id
GET http://localhost/test_users/#{photo.user_id}

從這邊可以確定一件事：

belongs_to 需要儲存 parent_id, 也需要一個 view:
parent_id => data

多對多的關係則比較複雜一點，但可能還比 RDBMS 簡單？

Photo.has n, :albums, :through => :photo_albums
Album.has n, :photos, :through => :photo_albums

應該用不到那個 :through, 只要兩邊都建立 view 即可。
test_photos 有 album_ids
test_albums 有 photo_ids
兩邊都需要一樣的 view:

for(i in photo.album_ids) emit(photo.album_ids[i], photo)

另一邊當然就是名字換一下而已。
因此當我們寫：

Album.get("id").photos 時會產生：

GET http://localhost/test_albums/id
GET http://localhost/test_photos/_views/album_id?
startkey=id&reduce=false

反之亦然。

因此需要事先定義的 view 有：

1. belongs_to
2. has n :through

當然啦，第一次讀取時再建立也不是不行。
而且搞不好這樣做反而比較好？總之是實作細節。

剩下沒辦法解決的問題則是在 join 中有條件的。
例如原本的：

all(permission.send(user.relationship(visitor)).not => :none,
permission.title.not => 'password',
:status => :common)

這超複雜就很麻煩..............
還有其他的條件，例如：

all(:status.not => :system)

像這種的大概就會需要臨時產生 view?
因為在 migrate 中沒辦法判斷有沒有這種操作。
或是說像是這樣：

Photo.new.methods(false).each(&:call)

強迫執行所有的 method, 以取得所有的可能需要的 view..
算了吧，條件式怎麼辦？
因此應該是兩種作法：

1. 動態產生 view
2. 要求 model 先寫好 view

前者可能會變成需要暖機之類的。
這倒是或許可以靠 test case 來處理...
如果有 100% coverage 的話，
可以確保 test 跑完所有 view 都產生了。

但其實事先寫好 view 也沒什麼不對，應該說本來就應該這樣！
缺點就是，與其他 adapter 就會出現不同介面..
所以想先試 1.
反正沒有衝突，真的有必要再手動補 view 吧。

all(:status.not => :system) 的話，可能就是...

if photo.status != :system
emit(null, photo)

GET http://localhost/test_photos/_views/status_not_system

因此這邊會需要把整個 ruby 的 query object,
compile 成 javascript...
然後產生一份 unique 的 name 當 view 的 name.

...這樣寫的話，速度應該超快，因為一堆 index,
但不知道會不會變成 database 超肥大...
折衷方式就是如果用 equal 判斷，例如：

all(:status => :system)

這樣就可以單純拿 status 做 index 即可，
startkey 用 system 就好。唔， not equal 可能會變成要兩次：

endkey=system
startkey=ststem

然後兩次接起來。到底哪個好，現在還沒釐清...
真的要做真的會很複雜哩 :(
看來 rdbms 大概是前人經驗都幫你想好了...
所以有 best practice 在那邊。
如果要改 couchdb 的話，怎麼做 model 就還要自己想。
又搞不好慢慢等別人分享經驗還比較快 @@

嘖。