0xd34df00d
06.02.2012 10:57 Azoth
Объебался кофе и понял, каким должно быть Хранилище в LC. Не нужны никакие Mongo и прочее, все вполне наворачивается поверх обычного скуэля. По дефолту будет постгрес, поэтому, кажется, вендоблядки соснут и останутся без хранилища для почты и прочих ништяков.
66 comments
recommend
bookmark
subscribe
а аперативки не будет мало?
в личкрафтах до сих пор нету глобального интерфейса для работы с базами?:
Тут не в интерфейсе для БД дело, а в ебанутом сторедже, чтобы все хранилось и няшно.
а разве sqlite не является стандартом де факто для desktop приложений? а то как то накладно поднимать sql сервер из-за десктопного приложения
Нет, почему7
sqlite тормознутое говно, которое едва ли может в concurrent access.
потому что у меня только гигабайт
640к хватит всем^U Ну, не вижу особых проблем, если честно.
я имею в виду — не стоит ли написать какую-то унифицированную хуиту, которая будет работать с базой, а все личкрафты с этой хуитой (это в коде) и так, что бы добавить туда работу с нужной базой не состоявляло особо труда. ОТогда вендобляди не соснут
охуел, оно жрет 600 мегабайт?
sqlite накладывает существенные ограничения по фичам, а я хочу использовать всю мощь постгреса.
Кто — оно?
на сколько я помню, sqlite имеет поддержку многопоточности. там надо только какой то флаг выставить.
кстати, есть извращенцы которые мелкие сайты поднимают на sqlite. а там точно много потоков.
Оно все равно тормозит, особенно при работе с одной таблицей из разных потоков, и иногда умудряется ломать транзакции.
LC
Нет, у меня на ноуте после старта 150-180 в полном комплекте и со всякими фильтрами-скриптами. У людей и в пару раз меньше жрет.
а ты, как норм кодер, заюзай ORM, тогда не будешь ограничен лишь одним движком базы
Расскажи мне про ORM в плюсах, дада.
тогда ок
во. Я про это и говорю. Надо написать свою же
как же вам тяжко живется. а как же делается прослойка между кодом и БД в плюсцах?
ORM тут, кстати, вообще ни при чем. На этапе, который мне нужен, уже нет никаких объектов, есть структуры данных с ромбовидной иерархией.
Руками.
короче напиши хуиту, которая позволит даже мне добавить туда мускул, что бы никто не соснул
страннота там у вас. надо поглядеть, что там гугел говорит...
напишите срази утилите a la akonadi-tray чтобы настраивать, контролить, выключить и пр
да ты гонишь. даже в qt есть орм — "QxOrm"
Когда я последний раз это ковырял, оно нихуя не умело.
И это не в куте, а сторонний солюшен же.
опиши
анус себе опиши, пёс
Есть еще qdjango, вроде многообещающе, но опять Qt-only, и какие-то проблемы с миграцией и прочей хуитой были.
Какой автоответ.
Зачем?
а что она тогда делает на офф сайте http://qt.nokia.com?
ага. но я серьезно про "опиши". интересно, до чего ты там дорисовался.
На сайте ноклы перечислены сторонние солюшены. В официальную поставку кутей они не входят.
для того, что бы никто не соснул и все были довольны. А мы поищем человека, который для этого заведет мускул. Не стоит так на раз отрубать венду
это же не страшно. главное — что она qt based
Чем мускл для венды лучше постгреса?
а может просто хватит QtSql? или там руками sql подсовывать надо?
тем, что она там заводится без бубна
да
Именно. QtSql — это тупо абстракция над нативными дровами для доступа к соответствующим БД. Выглядит как QSqlQuery query ("SELECT shit FROM crap;"); query.exec ();
это прескорбно.
> или
> да
спроси мантикора — он срал кирпичами из-за постргреса в венде
сарказмируешь, сука?!
Все состоит из айтемов. У айтемов может быть список дочерних айтемов и список родительских айтемов — получается такой ациклический направленный граф, для случая, когда у всех айтемов только один родитель, переходящий в дерево. Сначала описываешь структуру айтемов и говоришь, какое поле является ID, а какие будут легкими, и по ним ты хочешь уметь делать быстрые селекты, а какие — тяжелые, и их лучше хранить вне БД. Имеются методы для выбора всех айтемов данного типа, всех детей у данного айтема, и так далее.
В рамках этой модели, например, почта выглядит следующим образом. Фолдер — это айтем (который может быть сабфолдером, кстати). Письмо — это айтем, имеющий один или несколько родительских фолдеров. Индексируем по отправителю/теме/етц (по факту, храним эти поля в базе). Тело письма и аттачменты хранятся в виде файлов в ФС, в БД только пути к ним.
Есть utility-классы для представления всей этой хуйни в виде древовидной модели и все такое.
Это все нулевое приближение. Щас схожу прошвырнусь по улице, подумаю, как туда вписываются всякие календарики-хуе-мое, а также что я пока не учел.
http://en.wikipedia.org/wiki/List_of_obj...
QxOrm умеет больше всех.
он умеет: mysql, postgresql, sqlite, odbc
Там вопрос не в том, какие бекенды оно умеет, а в фичах типа версионирования, миграции, етц.
прочитал utility-классы как unity-классы. Чуть не обосрался
жаль
там буст и кути. Прямо сам бог велел засунуть это в личкарфты
Вообще охуеть.
обычно этим orm не занимается. самое лучшее поведение для orm — падать при старте, если что то не срастается.
мне кажется очень велосипедным. почему не просто activerecord и описание фолдера, мессаджа и т.п., и ручного указания "здесь индекс b-tree пожалуйста", "здесь has-индекс, пожалуйста". просто твоя абстракция напоминает мне Lucene и всю его xml-поебень — для полнотекстового поиска в вакууме неплохо, но когда ты точно знаешь, какие тебе индексы нужны и какие ты будешь делать запросы и какие у тебя модели — сложно описывать схему, сложно строить модели и т.п.
s/has/hash/
Потому что ручное указание не нужно. Про activerecord не понял, разверни.
Про люсьен телл ми моар, у меня в проекте по работе с ним все работает.
ну, ты делаешь обычный ООП, и объект маппится в запись в базе, такой паттерн. и отдельно умеешь маппинг его схемы в БД (а маппинг связывается с движком, который уже на конкретно постгрес). а иначе у тебя начнется "stringly-typed development", когда все схемы универсальны, никакой типизации и подобного.
ручное указание нужно, потому что как понять, какой тип индекса нужен и на какие поля? начнется описание схем и прочий люсьен.
насчет люсьена — я с ним конкретно не работал, а работал со всякими solr, а также riak и его копией схемы solr. так вот оно рассчитано как раз на минимальную привязку к структуре документа (судя по всему, ты тоже пытаешься), а потому всё, что нужно индексировать описывается xml-документом. так вот они пытаются сделать такой "универсвльный документ" под всё, а в результате получилось говно без compound-индексов, к примеру (это в riak, что там в solr не помню), ну и непонятно как оно индексирует по датам и прочему, в общем.
суть этого поста в том, что нужно оставаться ближе к схеме, т.к. на индексах нужно экономить и за ними следить (иначе память всю сожрут, или не будет multi-field index'ов, или еще что).
ах да. а деревья меня твои пугают немного :) нужны они ведь не везде, а придется теперь.
У меня еще есть и семантические роли столбцов и все такое. Хочу, чтобы движок автоматически мог связать колонку From в таблице почты и колонку Address в таблице адресной книги.
Ручное указание не того, какой тип индекса нужен, а того, по каким столбцам я буду делать выборки, и какие столбцы я обещаю не делать большими. В смысле, поле From обычно короткое, а вот тело письма может быть произвольно длинным, и тело письма в БД хранить неок.
Че. У нас вообще нет никакой структуры документа, мы индексируем плейнтекст. Кстати, индексер я тоже хочу в эту хуйню добавить, чтобы делать полнотекстовый поиск и все такое, но пока не придумал, чокак.
Они нужны как минимум в почте. А там, где не нужны — так пусть будет root item и у него все дети, или типа того.
Олсо, спасибо за начало конструктивного обсуждения всем в этом треде :3
тело письма хранить в бд как раз самый ок, тип поля называется textfield. а для ограниченых размером полей есть varchar(<length>). оно само будет выносить textfield'ы в хранилище умное. короче твоё дело лишь на уровне ОРМ указать.
короче не городи огород, делай а ля джанго-модели/формы. там же ты и прикрутишь, по сути, биндинг специальный к таблице адресной книги, в описнании модели.
по поводу люсьена — я имел в виду solr и его описание схемы, а не сам процесс хранения индекса и проч. короче там жуткий xml и пиздец.
а, по поводу пиздеца схем в солре — основной там в поисках по вайлдкардах, если не ошибаюсь. как-то очень сложно указать точность запросов твоих, он сам должен телепатически всё заиндексировать.
поэтому солр и жрёт столько тонн памяти, надо понимать.
Я не ебу, чо там в джанге.
ну и зря, хуле. ну может где-то в плюсах что-то подобное и есть.