You are here: Foswiki>Gnumed Web>DevelRefMiscRu (24 Feb 2013, IvanLykov)EditAttach

DevelRefMisc (Разнообразная справка разработчика)

AuditTrails

Ввод данных: разрешение конфликта параллелизма

  • Для получения дополнительной информации см. это сообщение
  • во время пользовательского взаимодействия строки не должны быть блокированы
  • перед указанием обновлений клиенты должны проверяться на изменения в данных
  • также см. регстроку в модуле gmBusinessDBObject.py
  • также, если интересно, этот поток сообщений
  • последняя статья (используя SELECT FOR UPDATE) по этой общей проблеме битов PostgreSQL суммирует общую концепцию
  • именно это мы делаем в промежуточном бизнес-объекте на основе класса и вот почему:
    • select for update
      • всякий раз, когда нужно убедиться, что можно смело писать в строку, в которой я должен сделать select for update
      • это не позволит другим транзакциям записи в этой строке до тех пор, пока я не освобожу эту блокировку через commit
    • checking XMIN
      • после моего select for update никто больше не сможет записать эту строку до тех пор, пока я не завершу
      • поэтому timespan между select for update и commit должны быть сведены к минимуму
      • поэтому я только select for update прямо перед фактической записью
      • однако, пользователь видел данные в окне гораздо раньше, а именно когда первоначально просто был сделан select
      • в то же время, другие могут перезаписать эти данные в базе данных (да, я видел, как это произошло)
      • они тоже должным образом блокировали данные, но блокировка освобождается снова, потому что они уже закончили свои записи
      • теперь я хочу записать свои изменения в бэкэнд
      • если никто больше не захватил строку, я могу сделать это независимо от того, что фактически находится в базе данных прямо сейчас
      • таким образом я могу переписать временные изменения других людей, некогда не подозревая, что они существовали
      • это недопустимо
      • поэтому я проверяю XMIN прежде, чем я пишу в бэкэнд
      • это должно быть то же самое значение XMIN, когда я изначально читал данные
      • или иначе кто-то тем временем переписал данные
      • XMIN является внутренней "timestamp" PostgreSQL, сообщающей мне, кто последний изменил данную строку
      • если XMIN изменен между моим чтением/отображением данных, а мне нужно cохранить изменения, я знаю, что кто-то еще изменил ее
      • в какой точке я должен сообщить пользователю об этом факте

API импортеров данных

все модули импортера в клиенте/импортерах определяют две функции

accept_file (file)

формирует файловый объект Питона и возвращает - True: я успешно импортировал этот файл (отсутствие соответствия пациентов не означает неудачу) - False: я не распознал этот формат, попробуй другой импортер - exception: я распознал формат, но имеется серьезная проблема (поврежденный файл или ошибка базы данных

и если это - результирующий формат: manual_match (человек, фрагмент) - человек является объектом gmPerson - фрагмент является фрагментом файла данных без соответствия, сохраненным опять в lab_result_unmatched, возвращает как выше True/False/exception

Тогда Gnumed может ответить в файл событиями drag'n'drop (до глупости легко в wxPython), и пробовать его импортировать. (плюс версия командной строки для запуска из procmail, fetchmail &c) Если никакой импортер его не распознает, мы можем получить всплывающий диалог для добавления его к серверу docs как "непрозрачный" файл.

См. также ImportersCountrySpecific

Типы данных - поля Character

В полях character используется тип TEXT

  • Я завел привычку использовать тип TEXT во всех полях character, на которые я наталкиваюсь в базе данных. Char(n) и varchar(n) в PostgreSQL PLUS обрабабываются так же, они требуют дополнительной отметки размера. Теперь эта проверка размера требуется, когда абсолютно никогда не будет никакого дополнительного строкового размера, помещаемого в данное поле, но я опасаюсь, что подавление такого ограничения на мгновение найдет случай, когда id не применяется. Теперь размер US SSN не нужно изменять, но мы не должны иметь поля, определенные в US SSN. И я не представляю особенностей других полей для строки определяемого размера для этого значения.--- Karsten http://mail.gnu.org/archive/html/gnumed-devel/2004-05/msg00156.html
  • знайте о другой вещи, что, если используете varchar и формируете дамп db, pg_dump пишет character, взамен varchar

Значения по умолчанию, где применимо, используют 'xxxDEFAULTxxx'

  • Как выбор значения по умолчанию, '__default__' был бы бедным переносом из Питона, потому что '_' имеет значение запросов LIKE, так и было бы '***default***', поскольку '*' имеет значение в регулярных выражениях. Опции считаются включенными '>>>default<<<' и установленными по рекомендации Хилмара 'xxxDEFAULTxxx' --- Karsten http://mail.gnu.org/archive/html/gnumed-devel/2004-01/msg00030.html

Менеджеры заготовок
  • Теперь имеются два менеджера заготовок на выбор
  • Код делает это легким для вас, предварительно выбирая тот, на который активно воздействуют.
  • Если действительно хотите использовать другой, то нужно преднамеренно изменить выбор и быть готовым исправлять ошибки.
  • Тот, который в конфигурационных таблицах назван "status_quo" является "default", он подходит наиболее близко к оригинальному механизму Хорста (например, ноутбук с плагинами) со все большим количеством механизмов, перенесенных от Ричарда (например, прививки, аллергия, области редактирования). Его часто называют Horst-space в отличие от Richard-space (непосредственно фоновый в технической документации GUI Ричарда - см. DevelopmentReference.

LDAP

Значения null vs клинических "negatives"

Клиент сети

Исконный клиент сети находится в
http://publicdb.gnumed.de:8080/gnumed-test-war
пользователь: tomcat , пароль: tomcat учтите, например, для поиска Кирка нужно щелкнуть гипертекстовую ссылку "clinical" для доступа к клиническим функциям
сообщения gnumed-devel на

Техническая документация

Whitepapers:
  • Техническая документация на CVS:
    • удобно читать через web-браузер ... просто откройте документ и щелкните ссылку "as text".
      • включает:
        • Краткий обзор архитектуры базы данных
        • Предоставляемые службы базы данных, включая personalia
        • Взаимодействие с бэкэндом
        • Внутренняя передача сообщений и посылка сигнала
        • Список доступных сигналов/сообщений
        • Книга записи на прием
        • Окно логина, краткий обзор
        • Браузер фармацевтических ссылок
        • Браузер кода
        • Диалог рецепта
        • Python shell (единственный и только)
        • Диалоговый SQL Window
    • опечатка:
      • требовалось разделение привилегий user/_user, но с тех пор отменено
        (17 июля 2004 - см. здесь)
  • принципы веб-сайта
Topic revision: 24 Feb 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark