Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 48 49 50 51 52 53 54 [55] 56 57   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3688
hvlad, по скорости выполнения и результату на 4-ке ничем.
Не знаю как именно в Огнептице, но так повелось, что для OR, как правило, не задан порядок вычисления аргументов и в зависимости от оптимизации порядок вычисления аргументов может быть изменён, а AND считается ленивым с порядком вычисления аргументов слева направо, так что если при вычислении первого аргумента результат FALSE, то второй аргумент не вычисляется.

На мой взгляд, запись с Coalesce более лаконична, хотя тут можно спорить, так как на NULL проверяется не :smthn, а результат вычисления table.field = :smthn, что равносильно:
CASE (table.field = :smthn) WHEN FALSE THEN FALSE ELSE TRUE END


Сообщение было отредактировано: 31 июл 20, 09:35
31 июл 20, 09:37    [22175944]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11381
rdb_dev
по скорости выполнения и результату на 4-ке ничем.
О чём тогда говорить ?

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

Кем там и что чем считается - его личное дело, мы не вмешиваемся.
31 июл 20, 10:19    [22175966]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 201
От ещё одна дурна идейка пришла в бошку:
Дать возможность плагинам определять свои типы данных.

Зачем это нужно: например, пишем набор UDF/R для работы с чем-нибудь сложным - деревом каким, графом, матрицей или чем-то подобным.
Но в текущем виде UDF/R могут принимать/отдавать только штатные типы.
Стало быть на входе/выходе наш замороченный объект придётся сериализовать/восстанавливать из блоба/строки.
Что может быть довольно накладно.

Как было бы хорошо: реализуем интерфейс с 2мя методами load и dump и разрешаем возвращать/принимать объекты с этим интерфейсом наряду со штатными типами.
В случае, ежели движек решит, что запись нужно сохранить - зовёт dump и получает блоб. Поднимает запись в память - зовёт load на блоб с данными.
А ежели сохранять/восстанавливать не нжно - объект живёт развёрнутый в памяти, что изрядно ускоряет с ним работу UDF/R.
9 сен 20, 19:05    [22194402]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53761

Tonal
Стало быть на входе/выходе наш замороченный объект придётся сериализовать/восстанавливать
из блоба/строки.
Что может быть довольно накладно.

Почему это накладно на штатном входе/выходе, но не накладно в абстрактных load/dump?
Других-то причин кроме "запись нужно сохранить" у выхода нет.

Posted via ActualForum NNTP Server 1.5

9 сен 20, 19:09    [22194403]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 201
Dimitry Sibiryakov,

Ну, например пусть у нас в блобе лежат xml-ки.
Нам нужно отфильтровать их по некоторым критериям, а потом из каждой выдернуть определённое поддерево.
Примерно так как-то бы выглядело:
select 
  t.id, 
  xml_dump(xml_xpath_first('//tag[@id="' | t.id | '"]', x.dom))
from table1 t
left join xml_parse(t.xml) x
where test_xpath('//tag[@id="' | t.id | '"]', x.dom) and test_xpath('//tag/info[@name="' | t.name | '"]', x.dom)

Здесь xml_parse создаёт объект dom с котрым работают test_xpath и xml_xpath_first.
А xml_dump просто вызывает штатный сериализатор dom-а и отдаёт блоб.
Если всё помещается в память, то load и dump вызываются по одному разу для каждой записи.

Сейчас мы должны всё через блоб гонять.
Т. е. отдельные xml_parse и xml_dump не нужны, но для test_xpath и xml_xpath_first получается 3 вызова внутренней load.
9 сен 20, 20:01    [22194434]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53761

Tonal
Сейчас мы должны всё через блоб гонять.

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

Posted via ActualForum NNTP Server 1.5

9 сен 20, 21:11    [22194457]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 201
Dimitry Sibiryakov
Не должны. Возвращаешь целое-хэндл или сразу указатель и всё.

А что получится, если движек таки решит что нужно сохранить запись с таким хэндлом/указателем и восстановить?
Мы получим указатели на мусор?
Как узнаем, что память под объект пора освобождать, когда движек сохранил запись с хенделом?
10 сен 20, 03:25    [22194511]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53761

Tonal
А что получится, если движек таки решит что нужно сохранить запись с таким
хэндлом/указателем и восстановить?

Движок ничего не решает. Решает программист, пишущий запрос.

Posted via ActualForum NNTP Server 1.5

10 сен 20, 12:33    [22194719]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10983
Dimitry Sibiryakov,

так или иначе должна быть привязка времени жизни этого хендла к времени жизни транзакции, как это сделал Адриано в пакете BLOB_UTILS. Потому что в обычном PSQL коде нет никакой гарантии, что дело дойдёт до функции закрытия хендла, и тогда он утечёт.
10 сен 20, 12:42    [22194725]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 201
Симонов Денис
в обычном PSQL коде нет никакой гарантии, что дело дойдёт до функции закрытия хендла, и тогда он утечёт.

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

То же самое внутри транзакции - данных слишком много, и движек решил что нужно сохранить их на диск - вызвал dump для каждого хендела и сохранил. При этом память освободилась.
А иначе - движек вроде всё на диск сбросил, а объекты в памяти висят, и освободят ея, хорошо если при завершении транзации. А то и до закрытия коннекта провисят, или вовсе до перезагрузки сервера...
11 сен 20, 17:39    [22195529]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
в дополнение к ALTER DATABASE END BACKUP
добавить команду ALTER DATABASE UNDO BACKUP (ну или как иначе назвать)
которая позволит отбросить все записанные в delta файл изменения и переведёт базу в нормальный режим работы (без использования nbackup.exe -F ...).
Это было бы удобно в ситуации когда проводится какая либо операция в базе с множеством промежуточных коммитов но если по какой либо причине возникла необходимость всё отменить то просто вывести базу из режима саписи в delta файл и отбросить этот дельта файл не сливая его с базой. Другими словами добиться атомарности при нескольких коммитах.
Это бы позволило даже при наличии резервной копии сильно экономить время при обновлении структуры базы данных и данных.
В принчипе это и так возножно через nbackup.exe -F ... но хотелось бы всё делать в рамках SQL скрипта без вызова сторонних программ и без остановки самого FB для "кражи" delta файла.

Спасибо.
21 май 21, 12:48    [22325232]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29902
hlopotun,

пиши в трекер feature request.
21 май 21, 16:17    [22325367]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
kdv
hlopotun,

пиши в трекер feature request.


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

Заголовок:
[Feature Request]:ALTER DATABASE UNDO BACKUP
Текст:
in addition to ALTER DATABASE END BACKUP
please add ALTER DATABASE **UNDO** BACKUP command.
The delta file must be deleted, the changes made to the delta file must be canceled. The database is switched to normal mode.
This will allow you to undo several commits at once and turn off the write mode to the delta file and discard this delta file without merging it into the database.
Unlike restoring from a backup, it is much faster to undo changes in the database (for example, when updating the program version and if the database is very large).
In principle, this is already possible through nbackup.exe -F ...
But I want to be able to do this within the SQL script without calling third-party programs and without stopping the server for the delta file deletion by hand.

Спасибо
21 май 21, 17:50    [22325437]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11113
... drop backup delta
.

P.S.
Но я бы завернул.
21 май 21, 19:20    [22325467]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53761

Это какая-то "метатранзакция" получается. Не скажу, что идея плохая, но данное предложение
выглядит как хак. По идее PITR для таких вещей должен использоваться.

Posted via ActualForum NNTP Server 1.5

21 май 21, 22:04    [22325540]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Gallemar
Member

Откуда:
Сообщений: 5554
Basil A. Sidorov
... drop backup delta
.

P.S.
Но я бы завернул.

Плюсую, костыль какой-то придумали.
22 май 21, 07:30    [22325619]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
Gallemar,

почему костыль, раз уж реализовали возможность писать в дельта файл, просто ещё одно применение.
Database Point in Time Restore как такового в FB нет, есть только инкрементная копия которая даёт состояние на момент начала резервного копирования а не как PITR на любой момент времени в рамках резервной копии. И время восстановления по сравнению с отбросом delta файла может на сутки отличаться на больших базах. Просто надо немного допилить и сделать нормальным. Ну или реализовать PITR как в том же Azure это сделано. При желании можно наложить ограничения,- что отброс delta возможен только если база в монопольном режиме использовалась.
Кстати есть возможность перевести базу FB в монопольный режим доступа кроме как через gfix?

Сообщение было отредактировано: 22 май 21, 17:01
22 май 21, 17:07    [22325718]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
Basil A. Sidorov
... drop backup delta
.

P.S.
Но я бы завернул.


да, звучит лучше
22 май 21, 17:08    [22325719]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
посмотрим

Сообщение было отредактировано: 22 май 21, 17:19
22 май 21, 17:27    [22325721]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hlopotun
Member

Откуда:
Сообщений: 498
спасибо RusMikle, закинул, посмотрим что ответят
22 май 21, 17:45    [22325727]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29902
hlopotun,

to all: там можно ставить лайки, и прочие смайлики. рекомендую.
23 май 21, 00:52    [22325790]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11113
Двухзвенка вообще и работа от имени владельца базы, в особенности - крайне распространены.
Поэтому возможность потерять данные в любой момент, а не только в процессе неудачного обновления - дыренная дыра.

P.S.
Возможно, что было бы разумно переместить весь такой функционал в сервисные функции.
Т.е. решить вопрос в идеологии: есть сервер, а есть базы, которые он может обслуживать. И сервисное обслуживание выполняется в рамках подключения к серверу, а не при подключении к базе.

Сообщение было отредактировано: 23 май 21, 07:32
23 май 21, 07:37    [22325796]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32594
23.05.2021 00:52, kdv пишет:
> to all: там можно ставить лайки, и прочие смайлики. рекомендую.

аккаунты с tracker.firebirdsql.org ***.
опять регаться на этом билгейцевом гите.
фэ!

Сообщение было отредактировано: 24 май 21, 12:38
24 май 21, 11:30    [22326105]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29902
Мимопроходящий,

ну, я тоже от github морщился, а потом пришлось зарегаться. Там дока по ФБ, и всякое. А теперь еще и трекер - мне ничего делать не пришлось, подписался и всё.
24 май 21, 12:31    [22326149]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 62982
Мимопроходящий> аккаунты с tracker.firebirdsql.org ***.

Старый трекер почил в бозе или что решили?

Posted via ActualForum NNTP Server 1.5

24 май 21, 15:20    [22326279]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 48 49 50 51 52 53 54 [55] 56 57   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить