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

[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, говоришь?

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

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

[sukhanchik]

Цитата:

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

Ну, дык пусть дорабатывают модуль, суки.

Злой ты. Но справедливый.

Если честно - я поэтому и спросил - что это такое. У меня ж в голове не укладывался тот факт, что тестировать систему можно не на самой системе. Это операционные системы пофиг на каком языке (C#, X++, VBA) тестировать. А тут-то вся фишка в коде. Если какая-нибудь функция ядра (FormDataSource.findRecord() к примеру) тормозит на больших объемах - то либо нужно рекомендовать обходной вариант (Best Practice), либо исправить в ядре, если это возможно. Сделали ж класс RecordInsertList для быстрой вставки данных. Вряд ли его тестировали "извне" .

А тут-то.... что-то из ядра не работает на большом объеме данных. И кто это проверит?
А с индексами меня вообще все умилило. Как можно тестировать алгоритм (скорость работы которого напрямую зависит от наличия правильных индексов) - не заморачиваясь на конфигурационные ключи? Предполагать что такой индекс есть, не зная о том, что у пользователя нет такого индекса? Или сразу, независимо от суммы оплаты давать пользователям лицензии на все, что есть в АХ? (т.к. тестируется только полная версия АХ, которой наверняка не стоит ни у одного клиента).

[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. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...

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

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