Выборка данных через AOS vs SQL Server

[kashperuk]

Ну, к примеру, создали заказ на продажу, обработали накладную, и хотим посмотреть, как выглядят складские проводки для строки заказа.

[fed]

Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.
Ведь для того тестовые скрипты и написали на C# чтобы не создавать проблем "квантового порядка", когда тестовые скрипты на X++ сами изменяют наблюдаемую среду. А получается что вы сначала все тестовые скрипты написали на C#, а потом сами же свою идею ломаете....

[mazzy]

Цитата:

Сообщение от fed

Ведь вы там, помниться, тестовые скрипты пишете не на Аксапте, а на C# или чем-то подобном ? Тогда я вообще не вижу ни одной причины чтобы через .net Business Connector доставать какие-то данные из базы. Получается что вы во первых сами геморроитесь по полной программе чтобы запросы через BC прогонять, а во вторых - есть некие шансы что вы будете периодически натыкаться на глюки самого BC, или созданная вами нагрузка будет напрягать сервер AOS и портить временные характеристики тестов.

А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме?

НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем.
пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#.

По-моему, так.

[fed]

Цитата:

Сообщение от mazzy

А я - вижу!
пусть натыкаются и исправляют глюки в BC.
пусть натыкаются и исправляют глюки в методах и классах доступа к данным
пусть натыкаются и исправляют проблемы с производительностью!!!

нафига НАМ (партнерам и клиентам) нужен какой-то левый инструмент, который Майкрософту (!) показывает "все ОК", хотя мы видим баг? Нафига нам нужен этот сферический конь в вакууме?

НАМ (партнерам и клиентам) нужно, чтобы правильно работал функционал, с которым МЫ работаем.
пусть пишут скрипты на Аксапте. либо пусть всю Аксапту переводят на C#.

По-моему, так.

Популизмом занимаешься.
Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).
Во вторых - то что средство тестирования и тестовая среда должны быть разделены - это некоторый очевидный постулат. Как я могу померить производительность системы, если средство измерения само съедает тики ? Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.

А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...

[mazzy]

Цитата:

Сообщение от fed

Дык тогда надо ДВА набора скриптов просто - один для тестирование .net bc, второй для тестирования все остального.

возвращаемся к первоисточнику

Цитата:

Сообщение от kashperuk

У нас тут небольшая дискуссия завязалась по поводу того, что лучше:
Выборка через АОС или выборка напрямую из SQL Server

(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).

про BC в первоисточнике ничего не было

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

Проблемы с производительностью надо выявлять. А не заметать под коврик прямыми запросами в SQL. ТОЧКА.
Проблемы с производительностью надо править в ядре и в стандартном функционале теми же средствами, которые юзают клиенты и партнеры. ТОЧКА.

[fed]

Цитата:

Сообщение от mazzy

возвращаемся к первоисточнику

про BC в первоисточнике ничего не было

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

Проблемы с производительностью надо выявлять. А не заметать под коврик прямыми запросами в SQL. ТОЧКА.
Проблемы с производительностью надо править в ядре и в стандартном функционале теми же средствами, которые юзают клиенты и партнеры. ТОЧКА.

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Дык вот для шагов 3,4 и (вероятно) 1 - .net bc и непрямой SQL не нужен совсем, если Ваньку начальство заставляет .net bc использовать для чтения базы на шагах 3 и 4 - это верх изврата.

[mazzy]

Цитата:

Сообщение от fed

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Замечательно.
Только пусть не на C#, а на X++.
В Аксапте же есть замечательный модуль UnitTesting.

Что-что? Фиговый, говоришь? В нем не хватает функционала, говоришь? Не хватает средств интеграции с VS, говоришь?

Ну, дык пусть дорабатывают модуль, суки. А не смываются в другую систему, которая недоступна для обычных клиентов.

Проблема одна: разработчики должны получать и исправлять те же самые баги, что и клиенты.
Если система тестирования работает с абсолютно другим механизмом доступа к данным, то с огромной вероятностью разработчики получат другой набор багов. В результате исправят не все баги, которые видят обычные клиенты. Что лично меня - не устраивает.

[nix0root]

Плюс прямых запросов при работе с Oracle это Hints.
Через AOS "подпихнуть" хинты мне так и не удалось

[mazzy]

Цитата:

Сообщение от fed

Популизмом занимаешься.

Как скажешь.
Я думаю, что высказал свое личное мнение и свою личную озабоченность происходящим.

Цитата:

Сообщение от fed

Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).

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

Если честно, то лично меня не устраивает механизм тестирования, который сильно отличается от стандартного механизма. Потому что сам механизм тестирования может содержать баги. Как и ядро может содержать баги.

Лично мне абсолютно пофигу где ошибка - в логистике, в ядре в алгоритме тестирования. Главное что она есть. И меня клиент заставит ее исправлять.

Лично я хочу видеть максимально похожий на стандартный механизм тестирования.
Только так я могу быть уверен, что разработчик получает при тестировании те же ошибки, что и я.
Только так я могу быть верить разработчикам (хоть с какой-то степенью).

Цитата:

Сообщение от fed

Во вторых - то что средство тестирования и тестовая среда должны быть разделены - это некоторый очевидный постулат. Как я могу померить производительность системы, если средство измерения само съедает тики?

Во-первых, это проблемы разработчиков
Во-вторых, во ходе замеров производительности никогда не оперируют абсолютными числами. Оперируют некими попугаями.

операция сложения - столько то попугаев.
операция деления - столько то попугаев.
операция доступа к записив базе - столько то попугаев.
а вот этот тривиальный алгоритм выборки суммы вдруг отжирает в несколько сот попугаев больше. значит надо разбираться с алгоритмом.

Где-то тут была тема со сравнением производительности арифметических операций в ax3, ax4, ax2009. Хоть там и говорилось про время. Но важны были относительные величины, а не абсолютные.

Цитата:

Сообщение от fed

Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.

Во-первых, это проблема разработчиков.
Во-вторых, это не повод использовать для валидации какие-то левые механизмы (см. первое сообщение в этой ветке )
В-третьих, тут также важны относительные значения. Вот этот алгоритм - столько то канареек, а вот этот в сотни раз больше.

Ну, не хочешь же ты сказать, что средство тестирования жрет память неконтролируемо. Ни за что не поверю.

Цитата:

Сообщение от fed

А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...

ну, прямые запросы к БД пишут по той же самой причине. Нормальный руководитель никогда бы такого не допустил.

Но обсуждение "управляемости проектом" - точно оффтопик в этой ветке.