ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / изменился rdb$generator_id
9 сообщений из 9, страница 1 из 1
изменился rdb$generator_id
    #38607791
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Доброго времени суток!
Делаю тут массированную перезакачку и одновременно чистку. В т.ч., делал backup_restore. В итоге обнаружил, что rdb$generator_id для моих генераторов уменьшился. Сталкиваюсь с этим впервые, хотя backup_restore делал и раньше, да и генераторы наверняка когда-то удалял. Это можно считать следствием удаления генератора с малым rdb$generator_id и последующим циклом backup_restore, или это что-то страшное?
...
Рейтинг: 0 / 0
08.04.2014, 00:38:47
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38607943
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
1. Да.
2. Это нестрашно и ничем не червато, если вы на этот ID нигде у себя логику не завязали.

P.S. А как вы вообще заметили уменьшение ID ? Это, практически, бесполезная инфа.
...
Рейтинг: 0 / 0
08.04.2014, 09:34:26
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38609072
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Гаджимурадов Рустам, завязывался. Для

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
create or alter procedure GENERATE_VALUE_BY_GENERATOR_ID (
    GENERATOR_ID integer)
returns (
    GENERATOR_VALUE integer)
as
begin 
  
  if (generator_id=26) then generator_value=gen_id(g_operation_line,1);
  else if (generator_id=22) then generator_value=gen_id(g_default,1);
  else exception e_debug('unknown generator'); 
  suspend;
 
 END^



У меня есть механизм ограниченного кеширования "дырок" значений генераторов. Когда запись удаляется, её id попадает в кеш "дырок" данного коннекта и может быть повторно этим коннектом использован для новой записи. Можно сбросить этот кеш в глобальный кеш, общий между всеми коннектами (естественно, это разумно делать по завершении удаляющей транзакции).

Кеш может хранить значения разных генераторов, а как их идентифицировать? По имени плохо, наверное, это же будет execute statement тогда. Вот я и применил код генератора.

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

Спасибо!
...
Рейтинг: 0 / 0
08.04.2014, 22:22:20
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38609132
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
budden> завязывался. Для

Ужас какой. :)

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

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

> У меня есть механизм ограниченного кеширования "дырок" значений генераторов

А с какой целью это делается, боитесь нехватки лимита?

> По имени плохо, наверное, это же будет execute statement тогда

Не будет там никакого ES/EB - просто в вызове ХП
подставите вместо номера генератора его имя.

> Хорошо, что всего два генератора и сработала защита.
> А то бы значения одного генератора попадали бы в кеш дырок другого

Если эта процедура используется не только для кеша, но и
для данных, могло быть гораздо хуже - неверные значения
попали бы в таблицы данных и искать и править их пришлось
бы уже вручную. А кеш сам по себе фигня - при попытке его
использования (вставки) всё равно сработали бы PK.

Ну и насчёт "кеша дырок" - кроме их "пула" есть ещё вариант
с не-удалением "дырочных" данных, а пометкой на удаление
(а-ля обычные статусы), с последующим редактированием
вместо insert-а, в случае если есть дырки - эдакий in-place кеш.
Проще в реализации, дешевле в работе и сопровождении, не
требует доп-таблиц. Детальные связи можно и нужно удалять,
конечно, остаются только сами дырочные ID-пустышки.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.04.2014, 00:11:21
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38612854
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Гаджимурадов Рустам, прошу прощения за долгое молчание.
> А с какой целью это делается, боитесь нехватки лимита?
Да, у меня много записей создаётся и удаляется.
> Во-вторых, назначение такой особенной процедуры для ровно двух генераторов нелогично и подозрительно,
Планировалось, что их будет больше, но как-то не разрослось в ту сторону. В принципе, сейчас можно присвоить им
условные номера 1 и 2 и на этом данная проблема исчезнет. На имя не хочу завязываться - неизвестно, как
это повлияет на производительность. Хотя, вероятно, влияние будет ничтожным, но это нужно проверять.

> Ну и насчёт "кеша дырок" - кроме их "пула" есть ещё вариант
> с не-удалением "дырочных" данных, а пометкой на удаление
> (а-ля обычные статусы), с последующим редактированием
> вместо insert-а, в случае если есть дырки - эдакий in-place кеш.
Ну можно было и так сделать, хотя не уверен, что это так уж сильно дешевле,
свои минусы тоже есть.
...
Рейтинг: 0 / 0
11.04.2014, 20:47:18
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38612863
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
buddenДа, у меня много записей создаётся и удаляется.
Что, целых 2^63 записей? Древнеперсидский шах, помнится, надорвался выставить такое
количество зёрен риса, а ты таки осилил?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.04.2014, 20:56:24
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38612890
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
budden> прошу прощения за долгое молчание.

Извиняться тут не за что, просто "старые" топики
я могу упустить из виду - отвечать будут другие.


budden> Да, у меня много записей создаётся и удаляется.

Ну, если специально не стараться, то лимита довольно сложно достичь.

> На имя не хочу завязываться - неизвестно,
> как это повлияет на производительность

Известно. Никак.

> не уверен, что это так уж сильно дешевле, свои минусы тоже есть.

Я не агитирую, плюсы и минусы везде есть.
Просто этот вариант проще вашего в реализации
и сопровождении. Насчёт производительности
не могу ничего гарантировать - сравнивать надо.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.04.2014, 21:49:21
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38619660
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Гаджимурадов Рустам,
спасибо. В общем, пока всё остаётся как есть, потом как-нибудь поправлю.
> Что, целых 2^63 записей?
Исторически сложилось, что id имеет тип integer. Менять это (в т.ч. в клиентских приложениях) - более трудоёмко, чем ввести кеш.
...
Рейтинг: 0 / 0
19.04.2014, 22:13:00
| Ответить | Цитировать | Написать  
изменился rdb$generator_id
    #38622693
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
buddenГаджимурадов Рустам,
> Что, целых 2^63 записей?
Исторически сложилось, что id имеет тип integer. Менять это (в т.ч. в клиентских приложениях) - более трудоёмко, чем ввести кеш.
2^31 согласен что меньше, но все же :)
...
Рейтинг: 0 / 0
23.04.2014, 11:38:24
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / изменился rdb$generator_id
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=97&tid=1563670]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 105ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 44ms
get tp. blocked users:
 2ms
others: 243ms
total:  434ms
созд. / загр.: 434ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]