Есть более радикальный способ: поставить RockBox. :)
Честно говоря, думал лучше об исходной прошивке айпода. Самому сталкиваться с ней не приходилось. Отсутствие хронологической сортировки раздражало бы неимоверно.
Замечательно! Кстати, в следующей версии Models всё, что связано с Pyrant, будет вынесено в models.backends.tyrant. Если все стандартные тесты Pyrant ваша ветка пройдет, с бэкендом проблем тоже не будет. Только надо подумать, как обеспечить взаимозаменяемость pyrant и tx-pyrant. Можно сделать доп. бэкенд на основе имеющегося (просто подменять класс Tyrant). Можно поступить как с факультативными сишными реализациями обычно, т.е. try/except с приоритетом tx (?). Ну и вообще интересно, есть ли смысл в существовании параллельных версий в перспективе.
Любопытно. В коде ничего не понял, но это, скорее всего, проблема чтеца. Особенно если учесть, что в репозитории не обучающий пример и не заранее продуманный проект, а потенциально полезный эксперимент (как и сами Pyrant и Models).
Вопрос: практическая польза оправдывает нелинейность кода и описанные вами потенциальные плавающие баги? Чем и как это можно измерить?
Вы, похоже, форкнули старую версию, которая лежит у Мартина. По-моему, лучше брать то, что на битбакете.
Про выборку ничего не понял, подожду кода с примером :)
Вообще, имхо, есть смысл стараться работать с каким-то одним из слоев (протокол, dict-like, query) и стараться сохранять API этого слоя. Это возможно в нашем случае или нет?
> пока не лезешь сильно глубоко, соотношение фич к неудобствам у Django Admin великолепное. [...] а если самому всё постоянно делать идеально, то и жизни не хватит!
Дык в том и проблема, что Django снимает множество вопросов, за что приходится платить позже. Как понадобится что-то, о чем авторы Django не думали, монолитность джанги ка-а-ак шабаркнет граблеручкой по лбу… Удивляться не приходится, ведь такова ниша проекта.
Писать с нуля всё целиком — затея не гиблая (ибо та же Django — результат такой затеи), но очень рискованная, тяжелая и требующая редкого сочетания личных качеств у авторов. Поэтому я и рассматриваю вариант с Pylons, где тоже всё более-менее готово, а связность компонентов не такая жесткая и можно экспериментировать свободнее.
Внешние приложения — половина могущества фреймворка. Терять их было бы печально. Но тут надо учесть, что ряд наиболее популярных из них включает в себя целые куски сырого SQL и поэтому в любом случае должен быть портирован на конкретный бэкенд. Может быть, со временем к тому и придем в рамках сохранения смысла слова «reusable». А пока особенной разницы между django-mptt-pyrant и models-mptt не видится. Кроме того, что последний можно было бы использовать не только в Джанге, но где угодно еще, включая консольные приложения. То же и с django-voting и подобными.
Некоторые существующие приложения при смене бэкенда вообще теряют смысл. Например, django-tagging в Tyrant реализуется обычным текстовым полем и лукапом __contains (хранилище само умеет различать tokens в строках и всяко эффективно искать по ним).
Ну и, да, часть сложных приложений жестко завязана на API различных компонентов Django и отвинтить всё это не представляется возможным: django-filter, django-photologue и т.д.; переписывать тяжело, и чтобы пользоваться ими, нужно написать джанговый бэкенд на базе Pyrant.
> во-первых, есть django-couchdb, из которого можно черпать вдохновение
Вдохновение ли. Мне кажется, там выбран довольно странный подход. Преимущества и особенности кауча игнорируются, база притягивается за уши к чужеродной среде. Карьерный экскаватор с реактивным двигателем.
> во-вторых, товарищи любители NoSQL для Django замышляют более удобные классы для поддержки нереляционных баз данных (в django-dev последние сообщения на эту тему тут и здесь),
Во-от, именно эту штуку я и жду :)
По-моему, у Вальдемара сейчас всё сломано. Я удовольствием занялся бы написанием бэкенда, когда будет более-менее стабильная нереляционная веточка, серьёзно метящая в транк. Впрочем, сейчас почитаю ссылки, мейби выяснится что-то новое и счастливое.
Грубо говоря, table_database = {'primary_key': '\x00'.join('name', 'john', 'age', '123')}
Т.е. табличный режим — просто надстройка над key/value. Главное щасье — в механизме поиска, который из коробки правильно работает с сериализованными значениями, не путает названия со значениями.
Тоже вариант. Но необходимость патчить джангу очень-очень сильно смущает. Я все проекты держу на транке. Нет более бездарной траты времени, чем поиски бага, вызванного недокументированным конфликтом библиотек и патчей. Именно поэтому мне кажется, что есть смысл подождать, пока тот же Вальдемар допилит и вольет в транк свой мегапатч. См. habrahabr.ru/blogs/python/80062/#comment_2354038
Мне пока не довелось работать с Twisted, поэтому чрезвычайно туманно представляю себе результат. Может, распишете подробнее с примерами? Не исключено, что в итоге был бы смысл так и сделать. Необходимость гибкого и легковесного (не)веб-фреймворка очевидна. Под «не-веб» имею в виду «слепой» сервер rest/json с возможностью втыкать нужную логику на питоне. Это очень похоже на CouchDB, но там мне не нравится навязывание «вывернутой» модели разработки. Попробуй замени бэкенд, когда всё твое приложение — middleware.
Под «document-oriented database» я понимаю хранилище записей произвольной структуры. CouchDB и MongoDB эту структуру хранят в JSON, а Tokyo Cabinet — в строке, которую расширение TDB дополнительно дробит на пары ключ/значение. Таким образом, кауч и монго вообще не накладывают ограничений на структуру документа, токио ограничивает вложенность (можно сериализовать значения, но тогда отрубится часть поисковых фич), а реляционные БД ограничивают еще и количество и типы свойств документа. Реляционные — это таблицы, а док.-ориент. — вменяемая реализация EAV, где entity — документ, а attribute/value — свойство документа.
Было бы славно! Ссылку добавил. Кстати, насчет PyMongo: есть ли смысл делать в Models бэкенд для неё? По-моему, было бы славно обеспечить в приложениях более-менее drop-in совместимость между разными бессхемными базами. Не знаю, как быть с каучем, но у MongoDB довольно стандартный API, клеевой код должен получиться тонким… или нет?
Спасибо) Models действительно пока дело только моих копытец, а Pyrant — плод коллективного труда. Будет славно, если со временем сформируется сообщество вокруг обоих проектов.
Я сначала хотел Pyrant прикрутить именно к Джанге, потому что пока всё делаю в ней, но после осмотра бэкенда для CouchDB мне кажется, что лучше немного подождать. Django ORM очень сильно привязан к SQL. Очевидно среди ведущих разработчиков пробудился интерес к schema-less/non-sql и какое-то движение началось, но я с трудом представляю себе, какой объем работы нужен для отвязывания моделей и механизмов запросов от подмножества БД, сколько эта работа может занять и кому попадет под хвост достаточно жгучая вожжа, чтобы таки эту самую работу сделать, а не просто поковыряться палочкой.
Кроме того, недавно надо было для джанговой админки сделать динамически генерируемые формы (EAV), так столько ржавых граблей обнаружилось под листвою, что мне уже эта админка кажется не таким уж и преимуществом. Во всяком случае, в нынешнем виде.
По-моему, проще взять какие-нибудь Pylons и воткнуть туда Pyrant с Models. Может быть, и новую админку написать-прицепить. В сущности, не так уж и много работы нужно, чтобы получить generic barebones админку (list/CRUD), основанную на какой-нибудь фреймворконезависимой форм-библиотеке. Джанговы формы хороши, но они же не единственные такие в мире. Можно и что-то ближе к Fulton сваять.
Что касается Models — просто в какой-то момент стало интересно, зачем в Джанге всё так сложно и нельзя ли проще. Как ни странно, оказалось, что можно %)
Оно пока сырое, но работает… Кстати, я еще не закоммитил новую версию, где Pyrant вынесен в backends. Так что можно админку делать для более широкой ниши.
Честно говоря, думал лучше об исходной прошивке айпода. Самому сталкиваться с ней не приходилось. Отсутствие хронологической сортировки раздражало бы неимоверно.
Вопрос: практическая польза оправдывает нелинейность кода и описанные вами потенциальные плавающие баги? Чем и как это можно измерить?
Про выборку ничего не понял, подожду кода с примером :)
Вообще, имхо, есть смысл стараться работать с каким-то одним из слоев (протокол, dict-like, query) и стараться сохранять API этого слоя. Это возможно в нашем случае или нет?
Дык в том и проблема, что Django снимает множество вопросов, за что приходится платить позже. Как понадобится что-то, о чем авторы Django не думали, монолитность джанги ка-а-ак шабаркнет граблеручкой по лбу… Удивляться не приходится, ведь такова ниша проекта.
Писать с нуля всё целиком — затея не гиблая (ибо та же Django — результат такой затеи), но очень рискованная, тяжелая и требующая редкого сочетания личных качеств у авторов. Поэтому я и рассматриваю вариант с Pylons, где тоже всё более-менее готово, а связность компонентов не такая жесткая и можно экспериментировать свободнее.
Внешние приложения — половина могущества фреймворка. Терять их было бы печально. Но тут надо учесть, что ряд наиболее популярных из них включает в себя целые куски сырого SQL и поэтому в любом случае должен быть портирован на конкретный бэкенд. Может быть, со временем к тому и придем в рамках сохранения смысла слова «reusable». А пока особенной разницы между django-mptt-pyrant и models-mptt не видится. Кроме того, что последний можно было бы использовать не только в Джанге, но где угодно еще, включая консольные приложения. То же и с django-voting и подобными.
Некоторые существующие приложения при смене бэкенда вообще теряют смысл. Например, django-tagging в Tyrant реализуется обычным текстовым полем и лукапом __contains (хранилище само умеет различать tokens в строках и всяко эффективно искать по ним).
Ну и, да, часть сложных приложений жестко завязана на API различных компонентов Django и отвинтить всё это не представляется возможным: django-filter, django-photologue и т.д.; переписывать тяжело, и чтобы пользоваться ими, нужно написать джанговый бэкенд на базе Pyrant.
> во-первых, есть django-couchdb, из которого можно черпать вдохновение
Вдохновение ли. Мне кажется, там выбран довольно странный подход. Преимущества и особенности кауча игнорируются, база притягивается за уши к чужеродной среде. Карьерный экскаватор с реактивным двигателем.
> во-вторых, товарищи любители NoSQL для Django замышляют более удобные классы для поддержки нереляционных баз данных (в django-dev последние сообщения на эту тему тут и здесь),
Во-от, именно эту штуку я и жду :)
По-моему, у Вальдемара сейчас всё сломано. Я удовольствием занялся бы написанием бэкенда, когда будет более-менее стабильная нереляционная веточка, серьёзно метящая в транк. Впрочем, сейчас почитаю ссылки, мейби выяснится что-то новое и счастливое.
table_database = {'primary_key': '\x00'.join('name', 'john', 'age', '123')}Т.е. табличный режим — просто надстройка над key/value. Главное щасье — в механизме поиска, который из коробки правильно работает с сериализованными значениями, не путает названия со значениями.
См. habrahabr.ru/blogs/python/80062/#comment_2354085
Pyrant написан МакДонеллом на базе кода Ипполито и Флоренцано, а затем значительно улучшен мною и lasizoillo.
Models написал я.
> Я бы привязал это дело к twisted наверное.
Мне пока не довелось работать с Twisted, поэтому чрезвычайно туманно представляю себе результат. Может, распишете подробнее с примерами? Не исключено, что в итоге был бы смысл так и сделать. Необходимость гибкого и легковесного (не)веб-фреймворка очевидна. Под «не-веб» имею в виду «слепой» сервер rest/json с возможностью втыкать нужную логику на питоне. Это очень похоже на CouchDB, но там мне не нравится навязывание «вывернутой» модели разработки. Попробуй замени бэкенд, когда всё твое приложение — middleware.
Под «document-oriented database» я понимаю хранилище записей произвольной структуры. CouchDB и MongoDB эту структуру хранят в JSON, а Tokyo Cabinet — в строке, которую расширение TDB дополнительно дробит на пары ключ/значение. Таким образом, кауч и монго вообще не накладывают ограничений на структуру документа, токио ограничивает вложенность (можно сериализовать значения, но тогда отрубится часть поисковых фич), а реляционные БД ограничивают еще и количество и типы свойств документа. Реляционные — это таблицы, а док.-ориент. — вменяемая реализация EAV, где entity — документ, а attribute/value — свойство документа.
Можно об этом почитать Катца (автора CouchDB) и комменты: damienkatz.net/2006/05/document_orient.html
А можно некоторые мои измышления (чуть устаревшие и скорее об RDF): neithere.net/dev/notes/databases/
Ну и какой-то обзорчик, собственно, покоится в википедии: en.wikipedia.org/wiki/Document-oriented_database
Кроме того, недавно надо было для джанговой админки сделать динамически генерируемые формы (EAV), так столько ржавых граблей обнаружилось под листвою, что мне уже эта админка кажется не таким уж и преимуществом. Во всяком случае, в нынешнем виде.
По-моему, проще взять какие-нибудь Pylons и воткнуть туда Pyrant с Models. Может быть, и новую админку написать-прицепить. В сущности, не так уж и много работы нужно, чтобы получить generic barebones админку (list/CRUD), основанную на какой-нибудь фреймворконезависимой форм-библиотеке. Джанговы формы хороши, но они же не единственные такие в мире. Можно и что-то ближе к Fulton сваять.
Что касается Models — просто в какой-то момент стало интересно, зачем в Джанге всё так сложно и нельзя ли проще. Как ни странно, оказалось, что можно %)
Оно пока сырое, но работает… Кстати, я еще не закоммитил новую версию, где Pyrant вынесен в backends. Так что можно админку делать для более широкой ниши.