Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
07.11.2011 16:35, Arioch пишет: В случае ошибки вероятно исключение всплывает наверх и проплывает через код, который знает из каких строк он исходные значения взял. Никакой код об этом не знает, ибо работает на основе BLR. А привязка BLR к SQL существует лишь на уровне команд целиком. -- Дмитрий Еманов
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
В письме от Fri, 04 Nov 2011 13:14:10 +0400, Dmitry Yemanov dim...@users.sf.net сообщал: А при arithmetic error что выводить? Движок понятия не имеет на этот момент, с какими строками/столбцами он работает. Код выполнения операций контекстно отвязан от выборки данных, ему все равно с чем работать на входе. Ну как-то он привязан же ? ведь результаты кладутся куда надо ? В случае ошибки вероятно исключение всплывает наверх и проплывает через код, который знает из каких строк он исходные значения взял. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
04.11.2011 1:22, Arioch пишет: А с какими данными это произошло? В какой строке в каком столбце какой таблицы ??? Ну и запросы у вас (с) а план запроса можно построить по BLR ? Конечно. Но причем тут план? select * from VIEW_VECTOR_COSINES Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS)) План любопытный - показываются вьюхи, а не таблицы - но при этом показывают PK от таблицЫ, а не от вьюх. Показывается как имя вьюхи (VECTOR_COSINES) так и имя/алиас таблицы внутри вьюхи (Q). Но зато есть статистика - а в статистике уже показаны не вьюхи, а таблицы!!! Причем тут статистика? Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то там, не помню уже), движок же может для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы, и для этих полей прочитать и сообщить значения ? Какие именно значения сообщить? Ну при нарушении PK/UK теоретически возможно сообщить значение ключа-дубликата. А при arithmetic error что выводить? Движок понятия не имеет на этот момент, с какими строками/столбцами он работает. Код выполнения операций контекстно отвязан от выборки данных, ему все равно с чем работать на входе. -- Дмитрий Еманов
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
В письме от Wed, 02 Nov 2011 23:03:07 +0400, Алексей Вишняков norrittmob...@googlemail.com сообщал: Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :) предложат - пройду но тут есть минимум два девела, кто инoгда может сразу влёт сказать фигня вопрос или нет и не надейтесь, это только кажется легко иногда полезно обсудить и до трекера. мой первый пост в этой ветке это доказывает :-) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
ФБ всегда сообщает о контексте ошибки (строка/столбец), если это произошло в процедуре. Если это не так - в трекер. Но при этом не сообщается, где именно в отдельном PSQL-запросе произошла ошибка. И я сильно не уверен, что такого стоит ожидать в ближайшем будущем. Для нормальной диагностики нужен исходный код проблемного места. Из дерева выполнения (или даже BLR) реконструировать его - мягко говоря непросто. А хранить debug info в разрезе синтаксических конструкций вместо текущих line-column - я вообще не уверен, что это правильный подход. Так что пока придется мириться с тем, что есть. -- Дмитрий Еманов
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
В письме от Thu, 03 Nov 2011 22:22:43 +0400, Dmitry Yemanov dim...@users.sf.net сообщал: ФБ всегда сообщает о контексте ошибки (строка/столбец), если это произошло в процедуре. Если это не так - в трекер. Ну сообщает. Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. At procedure 'DO_CALCULATIONS' line: 13, col: 2. А с какими данными это произошло? В какой строке в каком столбце какой таблицы ??? будущем. Для нормальной диагностики нужен исходный код проблемного места. Из дерева выполнения (или даже BLR) реконструировать его - мягко а план запроса можно построить по BLR ? вот я соотв. кусок из процедуры забиваю напрямую: select * from VIEW_VECTOR_COSINES Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS)) План любопытный - показываются вьюхи, а не таблицы - но при этом показывают PK от таблицЫ, а не от вьюх. Более сложный запрос: merge into metrics m using vector_angles_deg v on m.idx=v.metrics_idx when matched then update set m.turn = v.angle; Sorry, plan is unavailable for this statement... Ну ладно, хемуль с ним с планом, хотя раньше был, кажется. Но зато есть статистика - а в статистике уже показаны не вьюхи, а таблицы!!! Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то там, не помню уже), движок же может для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы, и для этих полей прочитать и сообщить значения ? В итоге это помогло бы точно определить на какие данных запрос сломался. И столбец, и строки Operations Read : 0 Writes : 0 Fetches: 51 Marks : 3 Enchanced Info: +--+---+---+-+-+-+-+--+--+--+ |Table Name| Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | Backouts | Purges | Expunges | | | Total | reads |reads| | | | | | | +--+---+---+-+-+-+-+--+--+--+ | METRICS| 0 | 1 | 0 | 1 | 0 | 0 |0 |0 |0 | | VECTORS| 0 | 1 | 2 | 0 | 0 | 0 |0 |0 |0 | +--+---+---+-+-+-+-+--+--+--+ -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov dim...@users.sf.net сообщал: 22.10.2011 9:21, Arioch пишет: Хорошая штука UPDATE с JOIN'ом :-) Чем MERGE не устроил? Вот Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и деление на ноль. В одной строке из множества. И все это внутри процедуры, хотя это и не так важно. Недостаток в том, что сообщив про деление на ноль, FB это просто констатирует, не сообщая где. Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов объединяются ещё две таблицы. Во всех таблицах есть PK, а в одной ещё и UNIQE индекс. Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в каком месте - было бы проще искать. Проанализировать таблицы, входящие в запрос, какие у них есть уникальные или PK-шные индексы, и добавить к сообщению об ошибке что-то типа Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = abc)); Table2(PK(Field1=2)); Table2(PK(Field1=-2)); Table3(PK(Field1=0)); -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :) С уважением, Алексей Вишняков 02.11.2011, в 23:00, Arioch the_ari...@nm.ru написал(а): В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov dim...@users.sf.net сообщал: 22.10.2011 9:21, Arioch пишет: Хорошая штука UPDATE с JOIN'ом :-) Чем MERGE не устроил? Вот Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и деление на ноль. В одной строке из множества. И все это внутри процедуры, хотя это и не так важно. Недостаток в том, что сообщив про деление на ноль, FB это просто констатирует, не сообщая где. Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов объединяются ещё две таблицы. Во всех таблицах есть PK, а в одной ещё и UNIQE индекс. Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в каком месте - было бы проще искать. Проанализировать таблицы, входящие в запрос, какие у них есть уникальные или PK-шные индексы, и добавить к сообщению об ошибке что-то типа Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = abc)); Table2(PK(Field1=2)); Table2(PK(Field1�)); Table3(PK(Field1=0)); -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov dim...@users.sf.net сообщал: Хорошая штука UPDATE с JOIN'ом :-) Чем MERGE не устроил? Упс SQL-2008 Пора кэш обновлять :-) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
22.10.2011 9:21, Arioch пишет: Хорошая штука UPDATE с JOIN'ом :-) Чем MERGE не устроил? -- Дмитрий Еманов
Развлекаясь с заменой переменыз и массивов на FB. update нa стероидах - ах если бы... :-)
М.б. и извращения, делать вычисления в SQL, но... В общем, экспериментирую по цепочке точек (траектории) посчитать углы поворота в каждой. Осталось из VIEW с посчитанными углами перенести данные обратно в таблицу точек. И хочется это красиво, пересечением множеств :-) Обе СУБД MS SQL и Firebird поддерживают обычный синтаксис оператора UPDATE. СУБД MS SQL также поддерживает синтаксис оператора UPDATE, в котором выполняется соединение (join) и производится обновление одной из таблиц соединения. Можно думать об этом как об условии WHERE на стероидах. Если такая функция очень нужна, то ее можно реализовать в СУБД Firebird с использованием представлений (views). Речь про update table1 set table1.column1 = table2.column2 from table2 where . Написана в целом логичная вещь, за парой исключений. Во первых VIEW вещь глобальная и напрваление каждому запросу свою вьюху настораживает Во-вторых, что, если источник данных - тоже VIEW с вычислениями? Поскольку VIEW увы не умеет быть частично обновляемый (относительно одних столбцов, но не других), то не проходит например CREATE OR ALTER VIEW UPDATE_METRICS( IDX, ANGLE, TURN) AS select t.idx, v.angle, t.turn from metrics t, vector_angles_deg v where v.metrics_idx = t.idx - update update_metrics set turn=angle - Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements. Attempt to execute an unprepared dynamic SQL statement. = обвязывать VIEW триггерами не интересно - тогда проще процедуру или execute block сделать. с курсором, императивно. но ведь не красиво перебирать курсором == Лобовое update metrics set turn = (select angle from vector_angles_deg where metrics_idx = idx) тоже некрасиво, императивненько. Да и выдаёт 42 чтения VECTORS на 7 обновлённых строк в METRICS PLAN JOIN (VECTOR_ANGLES_DEG VECTOR_ANGLES_RAD VECTOR_COSINES Q INDEX (PK_VECTORS), VECTOR_ANGLES_DEG VECTOR_ANGLES_RAD VECTOR_COSINES P INDEX (FK_VECTORS_1)) PLAN (METRICS NATURAL) Приятный декларативный бонус - обновляются все точки, в том числе первая и последняя, где никакuх углов нет: они заполняются NULL === execute block as declare variable id integer; declare variable an double precision; begin for select angle, metrics_idx from vector_angles_deg into :an, :id do update metrics set turn = :an where idx = :id; end; Жуть некрасивая. Зато какой хороший план, всего 5+6 чтений на 5 обновлений. Правда не заNULLяются остальные 2 строки metrics, придётся отдельно их заранее чистить, без фильтрации или с неэффективной фильтрацией where not exists. Но всё-равно не n^2 ! PLAN (METRICS INDEX (PK_METRICS)) PLAN JOIN (VECTOR_ANGLES_DEG VECTOR_ANGLES_RAD VECTOR_COSINES P NATURAL, VECTOR_ANGLES_DEG VECTOR_ANGLES_RAD VECTOR_COSINES Q INDEX (PK_VECTORS)) PS: С курсором не делал, но результат, думаю, будет идентичен. == Хорошая штука UPDATE с JOIN'ом :-) Ну и напоследок - с чем разлекался. Данные: insert into layers values (1, 1, null); insert into objects values (1,1,1,1,1, null); insert into metrics values (1, 0,3 ,1,null); insert into metrics values (2, 0,0 ,1,null); insert into metrics values (3, -4,0 ,1,null); insert into metrics values (4, -5,1 ,1,null); insert into metrics values (5, -6,1 ,1,null); insert into metrics values (6, -7,1 ,1,null); insert into metrics values (7, -6,1 ,1,null); execute procedure make_vectors; Cтруктура: CREATE GLOBAL TEMPORARY TABLE LAYERS ( IDX INTEGER NOT NULL, NUMBER INTEGER NOT NULL, NAMEVARCHAR(200) ) ON COMMIT DELETE ROWS; CREATE GLOBAL TEMPORARY TABLE METRICS ( IDX INTEGER NOT NULL, X INTEGER NOT NULL, Y INTEGER NOT NULL, OBJECT INTEGER NOT NULL, TURNDOUBLE PRECISION ) ON COMMIT DELETE ROWS; CREATE GLOBAL TEMPORARY TABLE OBJECTS ( IDXINTEGER NOT NULL, LAYER SMALLINT NOT NULL, OBJTYPESMALLINT NOT NULL, NUMBER SMALLINT NOT NULL, CODE INTEGER NOT NULL, SEMANTICS BLOB SUB_TYPE 1 SEGMENT SIZE 80 ) ON COMMIT DELETE ROWS; CREATE GLOBAL TEMPORARY TABLE VECTORS ( IDX INTEGER NOT NULL, X INTEGER NOT NULL, Y INTEGER NOT NULL, OBJECT INTEGER NOT NULL, LEN DOUBLE PRECISION NOT NULL ) ON COMMIT DELETE ROWS; ALTER TABLE LAYERS ADD CONSTRAINT PK_LAYERS PRIMARY KEY (IDX); ALTER TABLE METRICS ADD CONSTRAINT PK_METRICS PRIMARY KEY (IDX); ALTER TABLE OBJECTS ADD CONSTRAINT PK_OBJECTS PRIMARY KEY (IDX); ALTER TABLE VECTORS ADD CONSTRAINT PK_VECTORS PRIMARY KEY (IDX); ALTER TABLE LAYERS ADD CONSTRAINT UQ_LAYERS_NUM UNIQUE (NUMBER); ALTER TABLE OBJECTS ADD CONSTRAINT UQ_OBJECTS UNIQUE (NUMBER); ALTER TABLE VECTORS ADD CONSTRAINT FK_VECTORS_1 FOREIGN KEY (OBJECT) REFERENCES OBJECTS (NUMBER); ALTER TABLE VECTORS ADD CONSTRAINT FK_VECTORS_2 FOREIGN KEY (IDX) REFERENCES
