QST: QsT SQL Tools

[GraninAS]

Благодарю за отзывы, господа коллеги.

Мне не хотелось  бы, чтобы тема утонула в холиваре ORM vs SQL, тем паче, что позиция BaltikS'а мне ясна, аргументы не изменились, и смысла повторяться нет. Marat(Qt) прав, что оба подхода имеют право на существование. Каждый решает для себя, что ему нужно. Так же Marat(Qt) прав, что QST сейчас в зачаточном состоянии. С другой стороны, какая библиотека могла бы развиться, минуя данный этап? Я не считаю, что расхвалил библиотеку авансом, - я показал то, что она умеет и сказал, чего не умеет, прекрасно осознавая, что версия 0.3 весьма кривая даже в системе именования. Несколькими сообщениями ранее я рассказал, что в 0.4 версии это все пересматривается, посему стиль работы с QST будет постепенно приближаться к стилю работы в Qt. В частности, первое, что я сделал для этого, - переименовал все enum'ы (и я уже об этом упоминал выше). Вот примеры:

>   Functor                   CompareFunctor
>   fo_equal                  FunctorEqual
>   fb_left                   BracesLeft
>   SqlQueryTypes             QueryType
>   sql_select                QuerySelect
>   SqlFieldVisibility        FieldVisibility
>   fv_visible                FieldVisible
>   SqlFieldPurpose           FieldPurpose
>   fp_select                 PurposeSelect
>   fp_all_valued             PurposeAllValued_Mask
>   SqlFieldRoles             FieldRole
>   fr_id                     RolePrimaryKey
>   fr_parent                 RoleParentKey

и т.д. Как видим, главный пункт уважаемого Marat(Qt)'а и меня волновал давно...

Я выложил версию QST 0.4.1 pre-alpha.

Основные изменения.
- Рефакторинг имен.
- define'ы глобальных параметров (таких как SQL_VALUE_SET_DEFAULT_FUNCTORS) переименованы и перенесены в файл "qstglobal.h".
- QstAbstractModelHandler: устранено понятие источника данных. Теперь не нужно писать имя источника данных:

Код:

_productsHandler.reload(PRODUCTS, &_productsModel);
	_productsHandler.setTableView(ui->tv_Products);
_productsHandler.keyValueOfView()

- Создан класс QstAbstractItemNameExtractor, предназначенный для извлечения имени объекта в конструкциях вида "count([ID])"; "field AS FieldName"; "max(field) as [count]", "tableName AS alias". Класс задает интерфейс для создания собственных классов, реализующих извлечение имени.
- Создан класс QstDefaultItemNameExtractor, так же создан модульный тест для него - ut_QstDefaultItemNameExtractor.
- Класс QstBatch теперь позволяет загрузить любой класс типа QstAbstractItemNameExtractor. Если в методах указать, что требуется извлечение имени, то будет задействован этот класс. По умолчанию загружается QstDefaultItemNameExtractor.

Почти полный список можно посмотреть в файле "qst\0.3 beta to 0.4 pre-alpha Changes.txt".

На данный момент разрабатываю иерархические DFD, чтобы можно было создавать сложные вложенные SQL-запросы, а так же JOIN'ы. В планах еще много чего, так что пока к "заглоханию" особых предпосылок нет.

С уважением.

P.S. Рад любым дельным предложениям.

[immerrr]

с тех самых пор, как мне пришлось подержать в руках python django (фреймворк для написания веб-приложений и сайтов) и его ORM, я люто-бешено хочу заиметь такое "для души", т.е. в Qt. настолько хочу, что завидев автора, который, вроде, хочет что-то стоящее получить из своего творения, даже зарегался

причем, отдавая себе отчет в том, что в производительности я в лучшем случае не выиграю, то по крайней мере получить преимущество в

• синтаксисе
• упрощении поддержки кода
• уменьшении жесткости связей с БД
• использовании qt properties
• ... ну и всякого другого по мелочи

workflow моего "идеального орм" выглядел бы так:
1. подключил заголовок;
2. на метаязыке описал объекты, которые предполагается хранить в бд и, возможно, связи между ними;
3. написал бы метазапросы, которые бы, в принципе, были понятны человеку знакомому с SQL, но незнакомому с C++; что-нибудь вида,

Код:

  List<MyObject> list = MyObject::select_all("as o1").join(OtherObject::query("as o2"))
    .where("o1.somefield = ", myval);

или

Код:

  List<ID> list = MyObject::ids().where("anotherfield is NULL");

или даже

Код:

  QString q = MyObject::queryText("as o1").join(ThirdObject::query("as third"))
    .where("third.third_field IN ", array)
    .deleteFrom("o1");

Ну и само собой, в качестве бонусов, были бы неплохи замечательные нотации вида

Код:

  MyObject().setFieldOne(valOne).setFieldTwo(valTwo).store();

  MyObject object = MyObject::byId(some_id);

[GraninAS]

Уважаемый immerrr!

Ценю ваше внимание и приветствую ваш интерес к этой теме.

Очень хорошо, что вы написали "ORM вашей мечты", это поможет мне в направлении развития. На данный момент библиотека малоразвита и вещи, которые вы привели, маячат разве что на горизонте. Недавно я нашел еще один проект, содержащий в себе ORM. Развит он гораздо сильнее, чем мой, даром что появился недавно, - посмотрите, может, вам подойдет: QxOrm. Было бы очень интересно послушать ваше сравнение QxOrm и Django. Вот тема, где я несколько озадачен "конкурентами": http://www.prog.org.ru/topic_13249_0.html.

Добро пожаловать!

[GraninAS]

Я обновил проект на SourceForge.net. Точнее, залил обновленную QST 0.4.2a beta. Будет ли версия 0.4 доведена до релиза? Скорее да, чем нет. Бета-версия уже вполне надежная, никаких особых глюков там нет. Но я хочу добавить еще несколько интересных вещей, которых в 0.4a beta нет, но они есть в моих проектах.

SVN обновлю чуть позже.

(Эта версия была готова уже несколько месяцев назад, но я программист был бедный, без толкового Интернета. К счастью, и моим мучениям пришел конец. Ныне у меня есть безлимитка.)

Да, кстати. Сейчас один проект пишется на Qt+PostgreSQL, соответственно, я тестирую библиотеку в работе с этим сервером. Работает, - но работает до тех пор, пока не встретятся различия между простыми запросами в диалектах T-SQL и pgSQL.

Еще я сделал программу-пример для версии QST 0.4 - TradeDB 0.4 example, аналогичный пример есть на сервере для версии QST 0.3. СУБД - MS SQL Server 2000 (или выше). Для успешной компиляции ресурсы надо скопировать в папку с исходниками. Для успешного подключения - настроить источник данных ODBC с именем Trade, который указывает на базу данных. Еще нужно в самой базе данных пересоздать пользователей. Точно не помню, но там, кажется, пользователь и пароль "user". В любом случае, все эти настройки можно поменять в main.cpp.

TradeDB example src
TradeDB example - database
TradeDB 0.4 example - Resources


Какие изменения в бете по сравнению с альфой? Ну, их много.

0.4 pre-alpha to 0.4.2a beta Changes

- Документация кода обновлена.
- Добавлен класс QstIf.
- Изменены имена типов, перечислений:
* PurposeAllValued_Mask на PurposeValued_Mask
* QstFieldsVector на QstFieldVector
* QstValuesVector на QstValueVector
- Из модуля qstglobal.h убрана строка #include <QDebug>.
- Добавлен параметр QST_VALUE_NULL_SUBSTITUTE_BY_DEFAULT, установлен в #undefined.
- У перечислений уточнены числовые значения.
- Добавлено перечисление MatchPolicy.
- Добавлено перечисление QueryClause. (В будущих версиях перечисления FieldPurpose и QueryClause будут пересмотрены.)
- Добавлены типы QueryClauses, QueryClauseMap.
- Пересмотрены пространства имен.
- Удалена функция QstModelDescriptor::listView().

-= QstAbstractModelHandler =-

- У класса появился флаг _isLoaded, указывающий, была ли загружена модель.
- Косметические исправления внутри функций.
- Для генерирующих функий (_selector() и др.), а так же для функций вызова (Insert, Update и др.) у параметров queryNumber убрано значение по умолчанию. Поменяны местами 3 и 4 параметры.
- У функции _selector() убран параметр ModelType.

- Убраны функции:
* reload(QstPlainQueryModel*, QSqlDatabase &)
* reload(QstTreeQueryModel*, QSqlDatabase &)
* rowCount()
* DeleteCurrent(), SelectQuery(), InsertQuery(), UpdateQuery(), DeleteQuery(), ExecQuery()

- Добавлены функции:
* reload(QSqlDatabase &)
* isLoaded()
* setValuesMap()
* valuesMap()
* generateQuery()
* batch()

-= QstBatch =-

- Исправлена ошибка со строкой #include при подключении qstdefaultitemnameextractor.h и qstrolevisibility.h.
- Созданы классы QstFieldIf и QstSourceIf на основе QstIf.

Добавлены функции и операторы:
* addSource(QstSourceIf)
* addField(QstFieldIf)
* operator<<(QstSourceIf)
* operator<<(QstFieldIf)

-= QstDBConnection =-
- Добавлена возможность устанавливать порт. Для этого добавлены соответствующие варианты функций подключения и тестирования, а так же функция setPort().
- Конструктор класса теперь может принимать название драйвера.
- Название драйвера по умолчанию вынесено в константу QST_DEFAULT_DATABASE_DRIVER.

-= QstField =-
- Изменены параметры по умолчанию у некоторых конструкторов. (Ширина колонки, видимость поля и др.).
- Добавлен тип QstFieldNamesList (В последующих версиях имя может быть изменено на QstFieldNameList).

-= QstQueryComposer =-
- Исправлены ошибки, связаннае с генерацией секции WHERE и EXEC.
- Добавлена функция queryParts().
- Убраны классы EIllegalBetweenFoUsing и EInvalidSelectClause.

[GraninAS]

Приветствую всех!
Я выпустил первый Release Candidate для свой библиотеки, а именно - QST 0.4.2a rc. SVN тоже обновил.

0.4.2a beta to 0.4.2a rc Changes

- Добавлен возврат по ошибке из функции QstAbstractModelHandler::selectToMap(), а так же вывод QSqlError в отладочную консоль.
- Добавлена функция ModelType QstAbstractModelHandler::modelType().
- Добавлен класс QstConnectionSettings - настройки подключения.
- Добавлена функция QSqlError QstTreeQueryModel::lastError().
- Обновлена документация.

-= QstDBConnection =-
- Класс переработан.
- Настрйки подключения можно передавать в QstDBConnection внутри QstConnectionSettings.
- Добавлена функция QSqlError QstDBConnection::lastError().
- Добавлена функция QstConnectionSettings QstDBConnection::connectionSettings(const QString &connectionName).

Это были последние изменения функциональности для QST 0.4. Перед релизом я хочу написать еще несколько модульных тестов, которые, возможно, помогут найти какие-нибудь ошибки. Таким образом, версия 0.4 близится к завершению.

[GraninAS]

Добрый день, уважаемые!

Спешу сообщить, что сегодня у QST знаменательная дата: первый релиз, QST 0.4.2a release. Можно сказать, день рождения (поздравления принимаются!). Я с легким сердцем отпускаю QST 0.4 в массы и теперь могу работать над версией 0.5. Кстати же, в следующую версию я добавил уже несколько полезных вещей. В качестве подарка заинтересованным лицам выкладываю QST 0.5.1 pre-alpha. Важно: в ней генерируется диалект PostgreSQL, и запросы еще тестируются. Ошибки более чем возможны.

P.S. SVN обновлю в ближайшие нескольких дней.

Список изменений в 0.4.2a release сравнении с 0.4.2a rc.

- Улучшена стабильность release-сборки внутри класса QstAbstractModelHandler.
- Функции pModel() классов QstAbstractModelHandler и QstModelDescriptor переименованы в model().
- В QstModelDescriptor убран код, связанный с QListView - он нигде не использовался, поскольку QListView интерпретируется как QAbstractItemView наравне с QTableView и QTreeView.
- Функция QstQueryComposer::queryParts() теперь возвращает simplified() строки внутри QueryClauseMap.

- Исправлена ошибка в документации по классу QstQueryGenerator.
- Добавлен модульный тест ut_QstConnectionSettings.
- Обновлен модульный тест ut_QstQueryGenerator.
- Незначительно обновлена документация.

Список изменений 0.5.1 pre-alpha в сравнении с 0.4.2a release.

-= QstGlobal =-
- Добавлен элемент перечисления NullType::NotNull.
- Почти все элементы перечисления CompareFunctor были переименованы.
- Добавлены битовые функторы BitwiseOr, BitwiseAnd, BitwiseXor, BitwiseNot, BitwiseShiftLeft, BitwiseShiftRight.

-= Общее =-
- Добавлен QstLimit, добавлена генерация секции LIMIT.
- Из класса QstQueryComposer выведен класс _StringTemplate, переименован в QstStringTemplate и помещен в QstSpecial.
- Генерация SQL частично адаптирована для PostgreSQL (изменения в QstQueryComposer, QstQueryGenerator, querygenconstants.h).
- Обновлена документация.
- Добавлена генерация побитовых операций and, or, xor, lshift, rshift в секции WHERE.

-= QstAbstractModelHandler =-
- Добавлены функции viewFieldValue(), comboBoxFieldValue(), возвращающие данные поля из модели, привязанной к view или comboBox.
- Улучшена стабильность release-версии путем возврата из процедур, если параметры невалидны.
- Изменена логика функции clear() в сторону увеличения стабильности.
- Добавлены функции setViewCurrentRow(), setComboBoxCurrentRow() (тестируются).
- Добавлены функции viewFieldsValueMap(), comboBoxFieldsValueMap().
- Функция pModel() переименована в model().
- Функция value() отслеживает значение NullType.
- Добавлена функция setVariantMap().

-= QstPlainQueryModel =-
- Класс теперь - не переопределение QSqlQueryModel, а наследник.
- Прописана функция match() с ограниченным функционалом.

-= QstConnectionSettings =-
- Добавлена функция isDatabaseSettingsValid().

-= QstDBConnection =-
- Переписана логика создания подключений. Теперь экземпляр QSqlDatabase не хранится.
- Многие функции класса подверглись рефакторингу.
- Добавлена функция closeAll().
- Добавлены функции removeConnection() и removeAllConnections().
- Убраны функции rdb() и pdb().

-= QstModelDescriptor =-
- Функция pModel() переименована в model().

-= QstTreeQueryItem =-
- Функция setQuery(QSqlQuery) перенесена в секцию private.
- Добавлена заглушка на функцию match().

[mapron]

Здравствуйте, уважаемый Александр!
Прежде всего, хочу сказать что Вы делаете правильное и полезное дело. Пускай тут и пишут, что кроме Вас этого никому не надо, но я хочу сказать что это не так.
Просто большая часть людей просто берет и пользуется, и не говорит даже спасибо - менталитет такой.
Я последние два дня активно изучаю Вашу разработку, и хочу применить ее в образовательном проекте - ACM Server для нашего института (да я знаю что этих серверов - как грязи, но не монструозных и с понятным кодом ну и тем более на Qt - навряд ли )
Поэтому желаю Вам дальнейших успехов и обещаю присылать баги и пожелания если таковые будут:)

[GraninAS]

Приветствую и вас.

Спасибо за поддержку, она бывает очень нужна в минуты слабости. Я буду очень рад, если вам эта разработка пригодится. Будьте бдительны, ошибки и баги там, конечно, есть. Найдя их и сообщив мне, вы, таким образом, тоже поучаствуете в разработке, - я ценю это. Как и любые предложения по улучшению.

Большое спасибо!

Возможно, вам будет интересно узнать, что моя ORM для Qt - не единственная. Например, наибольшими возможностями из всех существующих обладает QxORM (http://www.qxorm.com/qxorm_en/home.html). Она очень специфическая, впрочем, как и любой инструмент. На главной странице этого продукта можно найти список других ORM, большая часть которых либо не для Qt, либо в самом зародыше.

[mapron]

Что она не единственная, я знаю - сюда попал с Вашего обзора на Хабре (хабр для меня рид-онли, что нисколько не огорчает).
QxORM я посмотрел, код ппц просто
Глобальный недостаток всех этих ORM - удаление от принципа KISS. Чем, кстати, страдает и Ваша разработка.
Я поиспользовав немного QST, понял, что очень много времени занимает ковыряние в исходниках для написания простейших запросов. Для меня это далеко для идеала.
Я вообще работаю веб-разработчиком и мне по душе, как сделана работа с моделями в Zend_Db и CakePHP-Model. Во второй, кстати, полноценная ORM.
Так вот я сейчас пишу подобную по духу систему:
{
delet(array("last_hit<?",dt.toString("yyyy-MM-dd hh:mm:ss")));
 insert(array("sid", sid, "uid", 0, "last_hit", QDateTime::currentDateTime().toString("yyyy-MM-dd hh:mm:ss")));

ModelSession sess;
sess.update(sess.array("uid",uid),sess.array("sid=?",req["sid"]));
QVariantHash mesess=sess.fetchRow(sess.array("sid",req["sid"]));
}

Вот примерно такие примеры кода. Если Вам будет интересно, свяжитесь со мной и мы обсудим скользкие моменты..

[mapron]

 на стиль использования системы меня натолкнули популярные фреймворки для PHP Zend_Db и cakePHP .
Любой кто знаком с их принципом, без проблем освоит и мою систему
в общем и целом мой ORM представляет собой два класса (даже полтора).
 Первый - это модель. Второй - это запись или объект
запись является наследником от QVariant и просто предоставляет более удобную работу с многомерными массивами и хеш-массивами
 а вот модель предоставляет собой обертку над всеми нужными функциями: insert, update, select и delete
select aka fetchAll & fetchRow  работает в двух режимах. В одном он получает sql-запрос с плейсхолдерами и вторым аргументам биндинг на плейсхолдеры. все прозаично. Самый низкоуровневый вариант
во втором режиме он получает в качестве аргументов а) where - хеш массив с плейсхолдерами ? - они заменяются на :-плейсхолдеры потом. б) order, limit компоненты - это пока в разработке. Я доделывают возможность по мере надобности в проекте
 кроме того, работу со связями (join-ы и отображение в зависимые элементы) хочется сделать подобным образом как в cakePHP. Просто заполняются нужные поля в конструкторе - и теперь в запросе findAll/Row в одном из полей результата будет содержаться зависимые объекты.
 в чем плюс моей системы. Программисту не надо запоминать кучу различных констант которые управляют его запросом
они либо пишет навороченные запросы руками и просто забивает их данными через биндинг, передавая второй аргумент , либо работает опять-таки с хеш-массивами (QVariantMap аналог) для условий и данных
т.е. ему нужно изучить ОДИН элемент, если он до этого работал уже с Qt и Sql и знает что такое update/insert/delete
Var: http://pastebin.com/4RBvXurA
примеры использования: http://pastebin.com/D2BBezkQ
Саму модель не выкладываю, ибо сыро, бажно и стыдно. Нет комментов и могут быть критические баги

[GraninAS]

Вы верно говорите об избыточности семантики многих ORM. И в большей части создатели стремятся уподобить код маперов SQL-языку, - по этому же пути идете и вы. Это интуитивный путь, его преимущество - в легкости восприятия. Не исключено, что в QST когда-нибудь так же появится что-то подобное. С другой стороны, в языках с динамической типизацией (PHP - самый яркий пример) сделать это проще, чем в С++, отчего для PHP существует, по крайней мере, две популярные и очень мощные ORM-системы. Будьте готовы к тому, что столкнетесь с трудностями синтаксического характера, когда будете достраивать свою ORM по аналогии с какой-нибудь другой навороченной ORM. Например, один из программистов Qt (если не ошибаюсь) хочет создать QDjango, - название этой ORM говорит само за себя. Благо, что С++ очень гибкий язык, и эту его гибкость в полной мере используют в библиотеке Qt; в противном случае создать свою Django было бы непросто. Могу еще сказать, что QST исповедует несколько иную философию. Когда все прочие проекты - это проекты по созданию ORM, то QST - это проект для создания библиотеки, облегчающей программирование БД. Отсюда и расхождения в подходах. Впрочем, пути примирения этих подходов есть, реальны и рассматриваются.

Ну а вам желаю успехов.

[vlad-mal]

Как-то глубоко проникал в данную область, проект тянул (не на С++, на Delphi с использованием BoldForDelphi).
В какой-то момент понял, что занимаюсь не разработкой, а борьбой с ограничениями модели.
Игрался с DB4O (чисто ООСУБД для java/.net, не ОРМ) - то же самое. Красота в простых примерах и ад при усложнении бизнес-модели.

ИМХО, применение простых организационные решений вроде разделения кода доступа к СУБД и бизнес-логики по отдельным модулям плюс написание тестов дадут больше, чем использование костылей вроде ORM.

Впрочем, вещь увлекательная и развивающая, удачи и удовольствия.

[mapron]

В какой-то момент понял, что занимаюсь не разработкой, а борьбой с ограничениями модели.

я полностью согласен. В фреймворке CakePHP мне не нравится то же самое, поэтому я больше придерживаюсь концепции Zend. фреймворк должен помогать ускорять РУТИНУ, а не навязывать свой стиль. Я должен всегда иметь возможность все сделать вручную, а методы фреймворка использовать лишь для облегчения. Я об этом и писал выше.
Я могу написать Var rows=model.fetchAll("большой и огромный составленный вручную запрос", биндинг);

[mapron]

ИМХО, применение простых организационные решений вроде разделения кода доступа к СУБД и бизнес-логики по отдельным модулям плюс написание тестов дадут больше, чем использование костылей вроде ORM.

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

Судя по тому что Вы называете ORM костылем у Вас либо был неудачный опыт в этом деле и Вы его неправильно готовили, либо Вы просто не имеете большого опыта в этой теме.

Я бы назвал существенным минусом ORM - при генерации реально сложных запросов и моделей нагрузка далека от оптимальной: извлечь объекты А; извлечь объекты Б, зависимые от А; извлечь объекты В, зависимые от Б; ну и т.п.
У меня есть идея как сделать "правильную" генерацию таких запросов (в данном примере 3 SQL-запроса) и я попробую ее воплотить

[mapron]

Будьте готовы к тому, что столкнетесь с трудностями синтаксического характера, когда будете достраивать свою ORM по аналогии с какой-нибудь другой навороченной ORM. Например, один из программистов Qt (если не ошибаюсь) хочет создать QDjango, ...

Вы меня так и не поняли до сих пор... я не хочу НАВОРОЧЕННУЮ ORM. я хочу ORM с минмумом возможностей, облегчающих написание кода, которая была бы МАКСИМУМ очевидна (в идеале - разобраться в которой 5-10 минут, почитав примеры). Заставлять пользователя курить маны для того чтобы городить кучу инициализаций с шаблонами и константами - это будет очень небольшой процент людей, да и то только если ORM будет предоставлять УНИКАЛЬНЫЕ возможности.

Надеюсь на Ваше понимание и жду дальнейшего обсуждения.