Zalecane podejście do ładowania dokumentów projektowych CouchDB w języku Python?

Question

Jestem bardzo nowy na kanapie, ale próbuję go użyć w nowym projekcie Pythona, a także chciałbym użyć Pythona do napisania dokumentów projektowych (widoków). Skonfigurowałem już Couch, aby używał serwera widoków couchpy i mogę to potwierdzić, wprowadzając pewne proste funkcje mapowania/zmniejszania do Futon.

Czy istnieją oficjalne zalecenia dotyczące ładowania/synchronizowania dokumentów projektowych podczas używania modułu couchdb w języku Python?

Rozumiem, że mogę publikować dokumenty projektowe, aby "zainstalować" je w kanapy, ale moje pytanie dotyczy najlepszych praktyk. Potrzebuję jakiejś strategii do wdrożenia, zarówno w środowiskach programistycznych, jak i środowiskach produkcyjnych. Moją intuicją jest stworzenie katalogu i przechowywanie tam wszystkich moich dokumentów projektowych, a następnie napisanie jakiegoś skryptu synchronizującego, który będzie ładował każdy z nich do kanapy (prawdopodobnie tylko ślepo nadpisuje to, co już tam jest). Czy to dobry pomysł?

Dokumentacja dla "Writing views in Python" to 5 zdań, a naprawdę po prostu wyjaśnia, jak zainstalować couchpy. Na project's google code site znajduje się wzmianka o module couchdb.design, który brzmi, jakby mógł pomóc, ale nie ma dokumentacji (którą mogę znaleźć). Kod źródłowy tego modułu wskazuje, że robi on większość tego, co mnie interesuje, ale zatrzymuje się on przed faktycznym ładowaniem plików. Myślę, że powinienem dokonać jakiegoś odkrycia modułu, ale słyszałem, że to nie jest Pythoniczne. Rada?

Edit:

W szczególności, idea przechowywania moją mapę/zmniejszenia funkcji wewnątrz napisowych wydaje całkowicie hacky. Chciałbym napisać prawdziwy kod Pythona, w prawdziwym module, w prawdziwym pakiecie, z prawdziwymi testami jednostkowymi. Od czasu do czasu chciałbym zsynchronizować mój pakiet "widok na kanapę" z instancją couchdb.

Answer 1

Oto podejście, które wydaje się uzasadnione. Najpierw podklasę couchdb.design.ViewDefinition. (Uwagi i pydocs usunięte dla zwięzłość.)

import couchdb.design 
import inflection 

DESIGN_NAME="version" 

class CurrentVersion(couchdb.design.ViewDefinition): 
    def __init__(self): 

     map_fun = self.__class__.map 

     if hasattr(self.__class__, "reduce"): 
      reduce_fun = self.__class__.reduce 
     else: 
      reduce_fun = None 

     super_args = (DESIGN_NAME, 
         inflection.underscore(self.__class__.__name__), 
         map_fun, 
         reduce_fun, 
         'python') 

     super(CurrentVersion, self).__init__(*super_args) 

    @staticmethod 
    def map(doc): 
     if 'version_key' in doc and 'created_ts' in doc: 
      yield (doc['version_key'], [doc['_id'], doc['created_ts']]) 

    @staticmethod 
    def reduce(keys, values, rereduce): 
     max_index = 0 

     for index, value in enumerate(values): 
      if value[1] > values[max_index][1]: 
       max_index = index 

     return values[max_index] 

Teraz, jeśli chcę synchronizować:

import couchdb.design 
from couchview.version import CurrentVersion 

db = get_couch_db() # omitted for brevity 
couchdb.design.ViewDefinition.sync_many(db, [CurrentVersion()], remove_missing=True) 

Korzyści z tego podejścia są:

1. organizacji. Wszystkie projekty/widoki istnieją jako moduły/klasy (odpowiednio) umieszczone w jednym pakiecie.
2. Rzeczywisty kod. Mój edytor tekstu podświetli składnię. Potrafię pisać testy jednostkowe przeciwko mojej funkcji mapowania/zmniejszania.

Podklasa ViewDefinition może być również używana do wysyłania zapytań.

current_version_view = couchview.version.CurrentVersion() 
result = current_version_view(self.db, key=version_key) 

To nie jest jeszcze gotowy do produkcji, ale myślę, że jest to duży krok w porównaniu do przechowywania mapę/zmniejszenia funkcji wewnątrz napisowych.

Edit: I w końcu napisał kilka postów na blogu na ten temat, ponieważ nie mogłem znaleźć żadnych innych źródeł rada:

• http://markhaase.com/2012/06/23/couchdb-views-in-python/
• http://markhaase.com/2012/07/01/unit-tests-for-python-couchdb-views/