Получить описание переменной

Удав

UKY написал(а):

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

Не доволен только повышением вероятности наделать ошибок просто очепятовшись или что-то не дописать в структурах.

Да пожалуйста

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

UKY написал(а):

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

Универсальность кода и скорость работы - понятия несовместимые.
В SAP Query подобное уже пытались реализовать. Что получилось - можете оценить сами :wink:

Единственный более-менее удачный пример - логические базы данных. Но универсальностью там не пахнет.

Кодер

UKY:

Цитата:

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

Угу-угу. и я понимаю почему неудобно! колесики у велика квадратные. да.
А ведь, старшно подумать, есть еще люди которым удобно использовать Select + проверки синтаксиса самого абапа!

Цитата:

Да, это велосипед, но он чертовски удобен.

Хм.. а выше Вы написали "не удобно". Вот ведь нестыковочка.
А теперь упражнение: подумайте, что скажут об этом остальные абаперы в вашей команде?

Цитата:

И аппликэйшену не обязательно тащить всю строку из кластерной таблицы и парсить её. Например, из кластера таблиц RFBLG можно безболезненно взять поля BUKRS, BELNR, GJAHR

Но другие поля да, придётся парсить

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

Code:

  SELECT bukrs belnr gjahr
    INTO TABLE lt_data
    FROM bseg
    FOR ALL ENTRIES IN lt_data
    WHERE bukrs = lt_data-bukrs AND belnr = lt_data-belnr AND gjahr = lt_data-gjahr .

А теперь - план!

Code:

SELECT
  "MANDT" , "BUKRS" , "BELNR" , "GJAHR" , "PAGENO" , "TIMESTMP" , "PAGELG" , "VARDATA"
FROM
  "RFBLG"
WHERE
  "MANDT" = :A0 AND "BUKRS" = :A1 AND "BELNR" = :A2 AND "GJAHR" = :A3
ORDER BY
  "MANDT" , "BUKRS" , "BELNR" , "GJAHR" , "PAGENO"
Execution Plan

 SELECT STATEMENT ( Estimated Costs = 1 , Estimated #Rows = 1 )

        2 TABLE ACCESS BY INDEX ROWID RFBLG
          ( Estim. Costs = 1 , Estim. #Rows = 1 )
          Estim. CPU-Costs = 5.795 Estim. IO-Costs = 1

            1 INDEX RANGE SCAN RFBLG~0
              ( Estim. Costs = 1 , Estim. #Rows = 1 )
              Search Columns: 4
              Estim. CPU-Costs = 4.313 Estim. IO-Costs = 1
              Access Predicates

Как видите, при любом раскладе, для выборки данных из кластера идет выборка всей строки таблы(скажите "гудбай" оптимизации выборок из BSEG и других кластеров)

не нравится ADB? ОК! есть еще и Query Service! нешто и персистенты вам не по нраву будут?

Цитата:

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

И с этой задаче отлично справляются(внимание, фанфары!) старый добрый SELECT + синтаксическая проверка!

AFH

UKY написал(а):

CORRESPONDING FIELDS OF не подходит ввиду его эффективности. Например, мне из BSEG нужно всего 4 ключевых поля (BUKRS, BELNR, GJAHR, BUZEI, которые можно вытянуть даже через index only scan), а если писать SELECT * INTO CORRESPONDING FIELDS СУБД придётся вытаскивать из таблицы и передавать по сети порядка 400 полей, которые мне совсем не нужны...

Пусть не BSEG, пусть обычная таблица. А вы тестировали это утверждение? Я в свое время пробовал померить насколько CORRESPONDING FIELDS OF работает медленнее других вариантов - так не получилось заметить существенной разницы. SELECT * INTO CORRESPONDING FIELDS - в SQL-трассировке выглядело как SELECT [выбор только необходимых полей]. Если код без динамических ухищрений то сервер приложений сам оптимизирует звездочку в селекте. По крайней мере у меня так получилось.

UKY

Удав написал(а):

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

Основы работы с выборками всё равно нужно. Как можно работать с выборками, не зная, как они работают? А время на изобретение не нужно - всё уже сделано и работает

Кодер написал(а):

А ведь, старшно подумать, есть еще люди которым удобно использовать Select + проверки синтаксиса самого абапа!

А мне и не страшно так думать. Сам люблю тёплый ламповый SELECT

Удав написал(а):

UKY написал(а):

Да, это велосипед, но он чертовски удобен.

Хм.. а выше Вы написали "не удобно". Вот ведь нестыковочка.

Не удобно лишь в плане проверки синтаксиса.
Но "чертовски удобно", что не нужно постоянно делать туеву хучу всевозможных проверок, удалений дубликатов, проверку на пустые ключи для выборки и были ли данные по выборке по пустым ключам, не нужно каждый раз заново изобретать буферные внутренние таблицы...
Ещё на основе этого метода сделана удобная обвёртка, которая при первом запуске делает выборку по множеству ключей и отдаёт только нужные данные, а при повторных запусках просто отдаёт нужные данные. Очень удобно использовать прямо внутри тела LOOP'а, чтобы выбрать все данные по всем строчках лупаемой таблицы и отдавать данные только по рабочей области этой таблицы.

Удав написал(а):

А теперь упражнение: подумайте, что скажут об этом остальные абаперы в вашей команде?

Конечно, изучать новое всегда сложнее. Но никто же не заставляет принудительно использовать этот велосипед?
А если вдруг нужно будет разобраться как это работает - всегда можно поставить точку останова на SELECT в методе и посмотреть, что он выбирает. Хотя, в большинстве случаях и так понятно, что делает метод с названием SELECT

Удав написал(а):

А теперь - план!

Code:

SELECT
  "MANDT" , "BUKRS" , "BELNR" , "GJAHR" , "PAGENO" , "TIMESTMP" , "PAGELG" , "VARDATA"
FROM
  "RFBLG"
WHERE
  "MANDT" = :A0 AND "BUKRS" = :A1 AND "BELNR" = :A2 AND "GJAHR" = :A3
ORDER BY
  "MANDT" , "BUKRS" , "BELNR" , "GJAHR" , "PAGENO"

Как видите, при любом раскладе, для выборки данных из кластера идет выборка всей строки таблы(скажите "гудбай" оптимизации выборок из BSEG и других кластеров)

Большое спасибо! Жаль, что SAP не настолько умён.
Тогда да, для кластерных таблиц подходит только одна мера оптимизации - не делать из них выборок вовсе

Удав написал(а):

нешто и персистенты вам не по нраву будут?

Да, к сожалению, тоже не по нраву

Опять же, там используется * в SELECT, да и ещё вдобавок ООП накручен по самое небалуй...

Удав написал(а):

Цитата:

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

И с этой задаче отлично справляются(внимание, фанфары!) старый добрый SELECT + синтаксическая проверка!

С этим я и не спорю

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

А ещё как-то встретилась такая интересная выборка, которая проходила проверку синтаксиса, но вываливалась в дамп после запуска:

Code:

SELECT SINGLE belnr gjahr
INTO lv_awkey
FROM bsik
WHERE bukrs = bukrs
AND belnr = belnr
AND gjahr = gjahr.

Видимо, в старых версиях сапа это работало, а в новых уже нет

Так что проверка синтаксиса тоже не всегда работает так, как мы от неё ожидаем

AFH написал(а):

SELECT * INTO CORRESPONDING FIELDS - в SQL-трассировке выглядело как SELECT [выбор только необходимых полей].

Ого, а вот это уже очень интересно! Огромное спасибо!

Запрос:

Code:

  SELECT *
    INTO CORRESPONDING FIELDS OF TABLE lt_mkpf
    FROM mkpf.

План:

Code:

SELECT
  "MBLNR", "MJAHR", "BUDAT"
FROM
  "MKPF"
WHERE
  "MANDT"=:A0

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

Минус один к плюс к моему велосипеду

Но остальные плюсы всё же остаются при нём

UKY

AFH написал(а):

Если код без динамических ухищрений то сервер приложений сам оптимизирует звездочку в селекте.

Мало того, даже такой код выбирает только необходимые поля:

Code:

  DATA:
    BEGIN OF lt_mkpf OCCURS 0,
      budat TYPE mkpf-budat,
      mblnr TYPE mkpf-mblnr,
      mjahr TYPE mkpf-mjahr,
    END OF lt_mkpf,
    lv_mkpf TYPE string.
  FIELD-SYMBOLS:
    <lt_mkpf> TYPE ANY TABLE.

  ASSIGN lt_mkpf[] TO <lt_mkpf>.

  lv_mkpf = 'MKPF'.
  SELECT *
    INTO CORRESPONDING FIELDS OF TABLE <lt_mkpf>
    FROM (lv_mkpf).

План:

Code:

SELECT
  "MBLNR", "MJAHR", "BUDAT"
FROM
  "MKPF"
WHERE
  "MANDT"=:A0

Это вообще классная тема.
Получается, у * только 1 недостаток - мэппинг полей на уровне приложения, но это не так уж и страшно.

Кодер

Видите ли, UKY,

Цитата:

Но никто же не заставляет принудительно использовать этот велосипед?

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

Далее: способ передачи условия where у вас выполняется через строку. А ее синт.анализ в дизайнтайме тоже ваша тулза делать будет? Вы понимаете, что таким образом увеличиваете количество мест, которые не чекаются в дизайнтайме, и могут быть причиной косяков в рантайме?

UKY

Кодер написал(а):

Используя его, Вы уже навязываете его изучение

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

Кодер написал(а):

Далее: способ передачи условия where у вас выполняется через строку. А ее синт.анализ в дизайнтайме тоже ваша тулза делать будет? Вы понимаете, что таким образом увеличиваете количество мест, которые не чекаются в дизайнтайме, и могут быть причиной косяков в рантайме?

Да, конечно понимаю. Поэтому и была создана эта тема

Удав

UKY написал(а):

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

Ваш "велосипед" не увеличивает скорость разработки. Легче написать и оптимизировать статический запрос, чем черный ящик. Особенно используя замеры производительности с помощью SE30/SAT :wink:

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

UKY написал(а):

Лично мне больше нравится читать короткий код, чем портянки на несколько тысяч строк...

такой?

Code:

SELECT (fields)
INTO TABLE lt_table
FROM (table)
WHERE (where)

И ошибки в названиях полей и таблиц только при выполнении программы обнаружатся :cry:

UKY

Удав написал(а):

Ваш "велосипед" не увеличивает скорость разработки.

Ещё как увеличивает. Именно благодаря этому велосипеду у меня и появилось время познакомиться с грамотными специалистами, обитающими на этом форуме, и уже узнать много нового для себя

Можно сравнить стандартный код с кодом, который использует метод, который я упоминал выше

UKY написал(а):

Ещё на основе этого метода сделана удобная обвёртка, которая при первом запуске делает выборку по множеству ключей и отдаёт только нужные данные, а при повторных запусках просто отдаёт нужные данные. Очень удобно использовать прямо внутри тела LOOP'а, чтобы выбрать все данные по всем строчках лупаемой таблицы и отдавать данные только по рабочей области этой таблицы.

Вот код с методом:

Code:

  LOOP AT it_key INTO ls_key.
    " Предварительная одноразовая выборка по всем it_key + фильтр по is_key
    zcldev_dyndatbuf=>fetch(
      EXPORTING
        it_key    = it_key
        is_key = is_key
        iv_table  = 'VBRK'
        iv_comp   = 'VBELN'
      IMPORTING
        e_data    = ls_vbrk
      CHANGING
        ct_all    = mct_vbrk
    ).

    LOOP AT mct_vbrk INTO ls_vbrk.
      " Предварительная одноразовая выборка по всем mct_vbrk + фильтр по ls_vbrk
      zcldev_dyndatbuf=>fetch(
        EXPORTING
          it_key    = mct_vbrk
          is_key = ls_vbrk
          iv_table  = 'VBRP'
          iv_comp   = 'VBELN'
        IMPORTING
          e_data    = ls_vbrp
        CHANGING
          ct_all    = mct_vbrp
      ).

      " Обработка ls_vbrp
    ENDLOOP.
  ENDLOOP.

Вот стандартный подход:

Code:

  DATA:
    lt_key LIKE it_key[],
    lt_vbrk LIKE mct_vbrk[].

  lt_key[] = it_key[].
  SORT lt_key BY vbeln.
  DELETE ADJACENT DUPLICATES FROM lt_key COMPARING vbeln.
  DELETE lt_key WHERE vbeln IS INITIAL.

  IF NOT lt_key[] IS INITIAL.
    SELECT vbeln vkorg kunrg fkdat inco1 waerk knumv zzvbeln zzfkdat
      INTO TABLE mct_vbrk
      FROM vbrk
      FOR ALL ENTRIES IN lt_key
      WHERE vbeln = lt_key-vbeln.

    lt_vbrk[] = mct_vbrk[].
    SORT lt_vbrk BY vbeln.
    DELETE ADJACENT DUPLICATES FROM lt_vbrk COMPARING vbeln.
    DELETE lt_vbrk WHERE vbeln IS INITIAL.

    IF NOT lt_vbrk[] IS INITIAL.
      SELECT vbeln posnr matnr arktx mvgr4 vrkme fkimg kzwi2 oicontnr
        INTO TABLE mct_vbrp
        FROM vbrp
        FOR ALL ENTRIES IN lt_vbrk
        WHERE vbeln = lt_vbrk-vbeln.
    ENDIF.
  ENDIF.

  LOOP AT it_key INTO is_key.
    LOOP AT mct_vbrk INTO ls_vbrk
                                WHERE vbeln = is_key-vbeln.
      READ TABLE lst_vbrp INTO ls_vbrp
                                WITH KEY vbeln = ls_vbrk-vbeln.
      IF sy-subrc = 0.
        " Обработка ls_vbrp
      ENDIF.
    ENDLOOP.
  ENDLOOP.

И это ещё очень простой пример. Если программа посложнее, то разница в размере кода будет ещё больше.

И в этом сравнении ещё не используются общие буферные внутренние таблицы, в которой хранятся все выбираемые данные для минимизации одинаковых выборок из БД, например, в модульном коде (куча методов/функций/перформов и т.п., которые выбирают одни и те же данные из СУБД).
Пример стандартного кода писать очень долго, а в моём методе достаточно создать по дополнительной внутренней таблице и добавить ещё один параметр в метод.

Особенно удобно вклиниваться в уже существующие отчёты.

Удав написал(а):

Легче написать и оптимизировать статический запрос, чем черный ящик.

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

Но чем сложнее написать это:

Code:

zcldev_dyndatbuf=>select(
  EXPORTING
    iv_table             = 'V_EQUI'
    i_key                = lt_equi
    iv_comp              = 'EQUNR'
  IMPORTING
    e_data               = lt_equi
).

По сравнению с этим?

Code:

DATA:
  lt_equi_buf LIKE lt_equi[].

lt_equi_buf[] = lt_equi[].
SORT lt_equi_buf BY equnr.
DELETE ADJACENT DUPLICATES FROM lt_equi_buf COMPARING equnr.
DELETE lt_equi_buf WHERE equnr IS INITIAL.

IF NOT lt_equi_buf[] IS INITIAL.
   SELECT * " теперь, оказывается, можно и так делать, а не перечислять все поля из lt_equi
     INTO CORRESPONDING FIELDS OF TABLE lt_equi
     FROM v_equi
     FOR ALL ENTRIES IN lt_equi_buf
     WHERE equnr = lt_equi_buf-equnr.
ENDIF.

И это ещё самый простейший пример, не говоря уже о более сложных запросах...

Удав написал(а):

Особенно используя замеры производительности с помощью SE30/SAT :wink:

А замеры производительности в SE30/SAT и так хорошо работают - этого не отнять

Показывается настоящий выполняемый запрос.
Единственный минус здесь - немного сложнее найти откуда пришёл этот запрос: в SAT приходится выбирать "Position in the Times Pool" и прокручивать немного вверх, чтобы перейти к нужной строчке кода.

Удав написал(а):

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

Начинающим программистам и так нужно учить SQL. Без него никак

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

Удав написал(а):

UKY написал(а):

Лично мне больше нравится читать короткий код, чем портянки на несколько тысяч строк...

такой?

Code:

SELECT (fields)
INTO TABLE lt_table
FROM (table)
WHERE (where)

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

Удав написал(а):

И ошибки в названиях полей и таблиц только при выполнении программы обнаружатся :cry:

Это да. С этим не поспоришь.
Поэтому я и создал эту тему, чтобы с этим помогли.

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

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

Кодер

Уу-у-у-у-у- как у вас тут все запущенно...(С) КВН

Цитата:

Вот код с методом:

Что? вытаскивание в цикле по одной записи? "производительность? не, не слышал". Такое выдергивание "по одному", по факту, будет давать офигенную нагрузку на БД

Цитата:

Вот стандартный подход:

Эта..
1. 2 селекта. Там где нужен 1 join или выборка из ракурса? Опять же: передавайте привет производительности
2. Сперва выбираем из таблы заголовка сд-фактур, по первичному ключу. Затем результирующую таблу зачем-то сортируем и удаляем дубли. Простите, а Вы и вправду думаете, что после первого запроса там могут быть дубли? Может надо-таки хоть раз посмотреть на содержимое таблы результата в отладке? ну или там хелп почитать?

Цитата:

И в этом сравнении ещё не используются общие буферные внутренние таблицы, в которой хранятся все выбираемые данные для минимизации одинаковых выборок из БД, например, в модульном коде (куча методов/функций/перформов и т.п., которые выбирают одни и те же данные из СУБД).

Думаете зря сапа буферизует не все подряд, а строго определенные данные? Буферизация того же vbrk-vbrp может занимать эгегей сколько памяти.

Цитата:

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

Проблема в том, что это - не гибкое использование. И, при необходимости написать хоть чуть-чуть более сложный запрос, будет происходить возврат к обычному нормальному инструменту. Ну вот самое простое: join-ы, вытаскивания данных "по-частям" при больших объемах обработки(это когда указывается package size в select\open cursor) и т.д.

Цитата:

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

Только этот тест будет тестировать правильность использования вашего инструмента, а не правильность функционирования самого ПО.

UKY

Кодер написал(а):

Уу-у-у-у-у- как у вас тут все запущенно...(С) КВН

Всё не так страшно, как Вы подумали

Кодер написал(а):

Что? вытаскивание в цикле по одной записи? "производительность? не, не слышал". Такое выдергивание "по одному", по факту, будет давать офигенную нагрузку на БД

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

Кодер написал(а):

1. 2 селекта. Там где нужен 1 join или выборка из ракурса? Опять же: передавайте привет производительности

JOIN не всегда хорош: не используется SAP BUFFERING, время на планирование запроса затрачивается больше, скорее всего, нельзя использовать халявную * в селекте с точки зрения производительности (сам не проверял, но интересно

).
Бывает, что JOIN-ом вообще нельзя: кластерные таблицы или типы полей не совпадают...

Кодер написал(а):

2. Сперва выбираем из таблы заголовка сд-фактур, по первичному ключу. Затем результирующую таблу зачем-то сортируем и удаляем дубли. Простите, а Вы и вправду думаете, что после первого запроса там могут быть дубли? Может надо-таки хоть раз посмотреть на содержимое таблы результата в отладке? ну или там хелп почитать?

Это был пример, который просто показывал возможности. Может быть любая другая таблица, в которой могут быть дубли или пустые данные.
Что за таблицы такие и какие у них первичные ключи я знаю. Можно ещё больше прооптимизировать этот алгоритм сразу выбирая из VBRP по IT_KEY, раз уж на то пошло

Кодер написал(а):

Думаете зря сапа буферизует не все подряд, а строго определенные данные? Буферизация того же vbrk-vbrp может занимать эгегей сколько памяти.

Конечно может занимать много памяти. Любой инструмент нужно использовать правильно.
Сапа не буферизует всё подряд просто потому, что она буферизует для всех программ на всё время работы сапы.
А здесь же буферизованые таблицы освободятся после выхода из транзакции. И это при условии использования буферизации, но никто не заставляет её обязательно использовать и при необходимости можно легко добавить.

Кодер написал(а):

Проблема в том, что это - не гибкое использование. И, при необходимости написать хоть чуть-чуть более сложный запрос, будет происходить возврат к обычному нормальному инструменту. Ну вот самое простое: join-ы, вытаскивания данных "по-частям" при больших объемах обработки(это когда указывается package size в select\open cursor) и т.д.

Это достаточно гибкий инструмент, который всегда можно расширить по желанию, в отличии от OPEN SQL. И этот инструмент в некоторых местах даже гибче OPEN SQL.
Вот, например:

Code:

  zcldev_dyndatbuf=>select(
    EXPORTING
      iv_table  = 'FLEET'
      it_key    = sst_equi
      iv_comp   = `OBJNR='IE'EQUNR FLEET_CAT=EQART`
    IMPORTING
      e_data    = ls_fleet
  ).

Это почти тоже самое, что и

Code:

  SELECT *
    INTO CORRESPONDING FIELDS OF ls_fleet
    FROM fleet
    FOR ALL ENTRIES IN sst_equi
    WHERE objnr = |IE{ sst_equi-equnr }|
    AND  fleet_cat = sst_equi-equart.

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

Разве что с JOIN-ом придётся туго, но пока не планируется в ближайшей перспективе его поддерживать, хотя это тоже возможно сделать.

А при обработке ОГРОМНЫХ массивов данных, для которых скорость работы критически важна конечно нужно использовать стандартные средства. Каждой задаче - свой инструмент

Кодер написал(а):

UKY написал(а):

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

Только этот тест будет тестировать правильность использования вашего инструмента, а не правильность функционирования самого ПО.

Имелось ввиду функциональное тестирование, а не покрытие кода тестами.
Покрытие тестами, покрывающие основную часть кода есть.
Я имел ввиду, что нужно обязательно тестировать с консультантами каждый участок кода с таким селектом.

Удав

UKY написал(а):

Каждой задаче - свой инструмент

Я не зря советовал посмотреть на SAP Query

Кодер

Цитата:

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

Я как раз читал внимательно. КОд читал. в коде цикл. Выхода из цикла нет. опаньки?

Цитата:

JOIN не всегда хорош: не используется SAP BUFFERING, время на планирование запроса затрачивается больше, скорее всего, нельзя использовать халявную * в селекте с точки зрения производительности (сам не проверял, но интересно

).

Да не всегда. Но в приведенном примере он вполне уместен и сработает хорошо

Цитата:

Это был пример, который просто показывал возможности.

И он отлично показал не возможности вашего инструмента, а как раз преимущества обычного open sql и грамотного его использования

Цитата:

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

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

Цитата:

Имелось ввиду функциональное тестирование, а не покрытие кода тестами.
Покрытие тестами, покрывающие основную часть кода есть.

Что-что, простите? Функциональное тестирование чего? вашего инструмента? вместо того, чтобы тестировать код разработанного ПО, теперь нужно тестировать код на соответствие вашему инструмента? Какая заманчивая перспектива-то! Вместо обычного набора проверка-расширенная проверка-код инспектор-тест.классы, теперь мы в цепочку добавим еще и ваши проверки. Перспектива просто безграничная.. По части поддержки вашей тулзы. ага.

UKY

Удав написал(а):

UKY написал(а):

Каждой задаче - свой инструмент

Я не зря советовал посмотреть на SAP Query

С SAP Query знаком только шапочно. Предпочитаю забыть его как страшный сон

Кодер написал(а):

Цитата:

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

Я как раз читал внимательно. КОд читал. в коде цикл. Выхода из цикла нет. опаньки?

Там ещё есть комментарий: "Предварительная одноразовая выборка по всем it_key". Ключевое слово одноразовая, что значит делается только один раз.
И ещё выдержка: "при первом запуске делает выборку по множеству ключей и отдаёт только нужные данные, а при повторных запусках просто отдаёт нужные данные".

Т.е. метод только один раз делает SELECT. А потом отдаёт данные из mct_vbrk/mct_vbrp.

Кодер написал(а):

Цитата:

Это был пример, который просто показывал возможности.

И он отлично показал не возможности вашего инструмента, а как раз преимущества обычного open sql и грамотного его использования

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

Кодер написал(а):

Цитата:

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

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

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

Кодер написал(а):

Цитата:

Имелось ввиду функциональное тестирование, а не покрытие кода тестами.
Покрытие тестами, покрывающие основную часть кода есть.

Что-что, простите? Функциональное тестирование чего? вашего инструмента? вместо того, чтобы тестировать код разработанного ПО, теперь нужно тестировать код на соответствие вашему инструмента? Какая заманчивая перспектива-то! Вместо обычного набора проверка-расширенная проверка-код инспектор-тест.классы, теперь мы в цепочку добавим еще и ваши проверки. Перспектива просто безграничная.. По части поддержки вашей тулзы. ага.

Функциональное тестирование - тестирование алгоритма работы ПО по ТЗ.
Думал, может неправильно употребил термин, но вроде всё в порядке судя по http://ru.wikipedia.org/wiki/%D4%F3%ED%EA%F6%E8%EE%ED%E0%EB%FC%ED%EE%E5_%F2%E5%F1%F2%E8%F0%EE%E2%E0%ED%E8%E5:

Цитата:

Функциональное тестирование — это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям.

Как же приятно, когда на форуме встречается парочка троллей, в ходе дискуссий которых рождаются такие интересные и полезные беседы

Жаль только, что по теме топика я не продвинулся ни на йоту

Кодер

Цитата:

Исправило. Мне не пришлось писать весь этот промежуточный код, который не несёт никакой практический смысл.

В случае выноса дублированных строк после выборки по первичному ключу - соглашусь. Действительно, смысла в вашем коде не было.
Вообще же разработчик обычно пишет код со смысломЖ в нормальном ПО каждая строка на своем месте для соответствия работы программы поставленному ТЗ.

Цитата:

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

Код не на ладони: с этим согласится даже подсветка синтаксиса abap редактора. У Вас в определении условий where теперь не видно где поле таблы, где условие, где константа.

Цитата:

Функциональное тестирование - тестирование алгоритма работы ПО по ТЗ.
Думал, может неправильно употребил термин, но вроде всё в порядке судя по http://ru.wikipedia.org/wiki/%D4%F3%ED% ... 0%ED%E8%E5:

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

... а ведь есть еще агрегирующие функции.. и есть еще выборка полей под одним именем, а затем - присвоение им псевдонима... а чтобы память не съедалась - выборка в ту же таблу, по которой был сделан FAE... возможность выборки в динамич.структуру созданную через create date...
И всего этого ваш инструмент будет лишён.

Правила форума

Получить описание переменной

Кто сейчас на конференции