Значение функции карты в couchdb-pythons ViewField

1

Я использую couchdb.mapping в одном из моих проектов. У меня есть класс под названием SupportCase, полученный из Document, который содержит все поля, которые я хочу.

Моя база данных (называемая admin) содержит несколько типов документов. У меня есть поле type во всех документах, которые я использую, чтобы различать их. У меня есть много документов типа "case", которые я хочу получить при использовании представления. У меня есть проектный документ под названием support с видом внутри него под названием cases. Если я запрошу результаты этого представления с помощью db.view("support/cases), я верну список Row, у которого есть то, что я хочу.

Тем не менее, я хочу каким-то образом обернуть класс SupportCase, чтобы я мог вызвать одну функцию и вернуть список всех SupportCase в системе. Я создал свойство ViewField

@ViewField.define('cases')
def all(self, doc):
    if doc.get("type","") == "case":
        yield doc["_id"], doc

Теперь, если я вызываю SupportCase.all(db), я возвращаю все случаи.

Я не понимаю, является ли это представление предварительно вычисленным и хранится в базе данных или выполняется по запросу, аналогично db.query. Если это последнее, это будет медленным, и я хочу использовать предварительно вычисленное представление. Как это сделать?

Теги:
couchdb
couchdb-python

3 ответа

3
Лучший ответ

Я думаю, что вам нужно:

@classmethod
def all(cls):
    result = cls.view(db, "support/all", include_docs=True)
    return result.rows

Document класс имеет метод class view, который переносит строки по классу, на который он вызывается. Таким образом, следующее возвращает вам ViewResult с строками типа SupportCase и принимает .rows of, который предоставляет список случаев поддержки.

SupportCase.view(db, viewname, include_docs=True)

И я не думаю, что вам нужно попасть в магию ViewField. Но позвольте мне объяснить, как это работает. Рассмотрим следующий пример из документации CouchDB-python.

class Person(Document):
     @ViewField.define('people')
     def by_name(doc):
         yield doc['name'], doc

Я думаю, что это эквивалентно:

class Person(Document):
    @classmethod
    def by_name(cls, db, **kw):
        return cls.view(db, **kw)

С исходной функцией, привязанной к People.by_name.map_fun.

Поделиться
  • 0
    Это работает. Я должен был спросить вас, прежде чем писать на SO. :)
0

ViewField использует предопределенное представление, поэтому после его создания будет быстро. Это определенно не использует временный вид.

Поделиться
  • 0
    Ну, этот факт для меня бесполезен, если я не могу указать, какой проектный документ он должен использовать. Я не хочу помещать функции map / lower в код своего приложения. Все, что я действительно хочу, это сказать что-то вроде SupportCase.all(db) и он должен возвращать все случаи, заключенные в класс Document SupportCase .
  • 0
    Я на самом деле согласен, и я надеюсь изменить CouchDB, чтобы справиться с этим лучше. Тем не менее, вы действительно спросили о том, использует ли ViewField предварительно вычисленное представление или db.query.
Показать ещё 1 комментарий
0

Функция отображения в некотором роде аналогична индексу в реляционной базе данных. Это делается не каждый раз, и когда новые документы добавляются, то, как он обновляется, не требует, чтобы все было переделано (это своего рода древовидная структура).

Это довольно хороший summary

Поделиться
  • 0
    Я знаю, что это такое и как оно поддерживается. Проектный документ должен содержать карту и функции сокращения, и он вычисляется постепенно. Если это так, то что делает приведенное выше определение функции? Это в коде. Это должно быть в базе данных (если это не временное представление). Другими словами, меня особенно интересует, как работает библиотека coucdhb-python, а не сама кушетка.
  • 0
    Если вы просто хотите получить результаты представления, которые звучат так, как вы хотите, тогда лучше использовать db.view ("_ design / myapp / _view"). У меня лично нет проблем с созданием / определением представления в couchdb, возможно, с использованием futon, а затем просто с доступом к результатам в python. Если по какой-то причине вы хотите, чтобы весь код был в python, то вы можете использовать приведенный выше код для определения в python. Но я бы порекомендовал просто определить представление в кушетке напрямую и только вернуть результаты в python. Есть ли причина, по которой db.view не подходит для ваших целей?
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню