Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov,
Вы не правы по всем трем пунктам. Но так как читать вы не умеете и в предметную область вникать не можете, в чем-то вас убеждать я не буду
30 мар 19, 15:28    [21847835]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27915
superspy2019
Read_committed readonly транзакция не вынуждает собирать версии, но потребует заблокировать нужные записи, иначе нельзя гарантировать консистентность, о чем абсолютно точно сказал H5N1. Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам использует вариант no_record_version, что приводит к двухфазной блокировке и дает исключение при попытке прочитать неконсистентный набор.

честное слово, большей ахинеи про версионность в ФБ я нигде не читал.

какие еще, ..., каноны? Где "по умолчанию использует no_rec_version"? Какая еще "двухфазная блокировка"?
Вы не просто бредите, вы в другой вселенной находитесь.
30 мар 19, 15:40    [21847841]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27915
superspy2019
Вы не правы по всем трем пунктам. Но так как читать вы не умеете и в предметную область вникать не можете, в чем-то вас убеждать я не буду

гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной. Это ВЫ читать не умеете, о чем и заявляете с непомерным пафосом.

А чтобы не подвергнуться аналогичным обвинениям с вашей стороны, на всякий случай сообщу, что ibase.ru это мой сайт, и я и есть kdv, который написал тучу статей про версионность, сборку мусора, транзакции, и так далее.
И если вы собираетесь на эту тему что-то еще брякнуть, то рекомендую ПЕРЕЧИТАТЬ эти самые статьи.
30 мар 19, 15:43    [21847844]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 59689
kdv> гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной.

Вы, Шариков, чепуху говорите. И возмутительнее всего
то, что говорите её безапелляционно и уверенно. (с)

Не мешай человеку буйно ламерствовать.

Posted via ActualForum NNTP Server 1.5

30 мар 19, 15:51    [21847852]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

Кстати о птичках:
[quot superspy2019]
Причем Firebird (знаю только про 2.5) по умолчанию вопреки канонам использует вариант
no_record_version, что приводит к двухфазной блокировке и дает исключение при попытке
прочитать неконсистентный набор.
[quot]
Умолчание для read_committed это no_rec_version + wait, которое (до некоторой
степени) позволяет эмулировать каноническое поведение Оракула с его lost writes.
Так что насчёт канонов ты тоже неправ.

А для получения исключений неопытный (криворукий) разработчик должен явно установить
read_committed + nowait, что уже совсем не умолчание.

Posted via ActualForum NNTP Server 1.5

30 мар 19, 16:15    [21847865]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
kdv
честное слово, большей ахинеи про версионность в ФБ я нигде не читал.

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

kdv
гражданин, я вас уверяю - вы несёте ахинею, и при этом считаете её истиной. Это ВЫ читать не умеете, о чем и заявляете с непомерным пафосом.

А чтобы не подвергнуться аналогичным обвинениям с вашей стороны, на всякий случай сообщу, что ibase.ru это мой сайт, и я и есть kdv, который написал тучу статей про версионность, сборку мусора, транзакции, и так далее.
И если вы собираетесь на эту тему что-то еще брякнуть, то рекомендую ПЕРЕЧИТАТЬ эти самые статьи.


Добрый день.
Если я в чем-то заблуждаюсь, то охотно выслушаю истину в последней инстанции. Я в общем-то, за этим на форум и обратился.
И злиться совершенно не обязательно (если это, конечно, не ваш режим по-умолчанию), я к этому никого не принуждаю. Сведения про работу с транзакциями черпаю отсюда: http://www.ibase.ru/files/firebird/langref25rus/index.html#transaction.

Цитирую:
NO RECORD_VERSION (значение по умолчанию) является в некотором роде механизмом двухфазной блокировки. В этом случае транзакция не может прочитать любую запись, которая была изменена параллельной активной (неподтвержденной) транзакцией.
Если указана стратегия разрешения блокировок NO WAIT, то будет немедленно выдано соответствующее исключение.

Если вы пришли сказать что-то конструктивное, интересно будет услышать комментарий в контексте ваших сообщений - в чем конкретно я ошибся.
30 мар 19, 16:50    [21847877]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
А для получения исключений неопытный (криворукий) разработчик должен явно установить
read_committed + nowait, что уже совсем не умолчание.


Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается, если параллельная транзакция не была отменена по истечению таймаута. Или не забыли, а явно пытаетесь вводить в заблуждение. Не знаю.
30 мар 19, 16:55    [21847880]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
Нужно что-то вроде этого?

select r.NAME, f.NAME, t.RDB$TRIGGER_NAME
from (select RDB$RELATION_NAME
      from RDB$RELATIONS
      where RDB$RELATION_NAME = 'RDB$RELATIONS'
      union all
      select null
      from RDB$DATABASE) as r(NAME)
left join (select RDB$FIELD_NAME
           from RDB$RELATION_FIELDS
           where RDB$RELATION_NAME = 'RDB$RELATIONS'
           union all
           select null
           from RDB$DATABASE) as f(NAME) on r.NAME is null
left join RDB$TRIGGERS t on t.RDB$RELATION_NAME = 'RDB$RELATIONS' and f.NAME is null and r.NAME is null


но профессионалы для передачи таких структур используют XML или JSON
30 мар 19, 17:02    [21847882]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
Нужно что-то вроде этого?

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

vvvait
но профессионалы для передачи таких структур используют XML или JSON

Тоже про это думал, но как-то диковато выглядит... Одной строкой не передать, придется теги как-то размазывать, а на клиенте собирать и десериализовывать.
30 мар 19, 17:10    [21847884]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
но профессионалы для передачи таких структур используют XML или JSON


Если конечно эта фраза была написана в отношении формата получаемых от БД данных.
Могу придумать только собирать схему вложенными for select и суспендить из хранимой процедуры. Очень интересно посмотреть на производительность в деле. Очень сомневаюсь
30 мар 19, 17:20    [21847890]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
для большего кол-ва полей расписывать не стану
select r.NAME, r.ID, f.NAME, f.ID, t.RDB$TRIGGER_NAME, t.RDB$TRIGGER_TYPE
from (select RDB$RELATION_NAME, RDB$RELATION_ID
      from RDB$RELATIONS
      where RDB$RELATION_NAME = 'RDB$RELATIONS'
      union all
      select null, null
      from RDB$DATABASE) as r(NAME, ID)
left join (select RDB$FIELD_NAME, RDB$FIELD_ID
           from RDB$RELATION_FIELDS
           where RDB$RELATION_NAME = 'RDB$RELATIONS'
           union all
           select null, null
           from RDB$DATABASE) as f(NAME, ID) on r.NAME is null
left join RDB$TRIGGERS t on t.RDB$RELATION_NAME = 'RDB$RELATIONS' and f.NAME is null and r.NAME is null


в выгрузке в xml нет никаких сложностей, отчеты мы например в виде готового html сразу из базы получаем
30 мар 19, 17:21    [21847891]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
с left join-ами - плохой путь. в какой-то момент можно уперется в ограничение на размер кортежа 64 кб, придётся всё к блобам приводить
30 мар 19, 17:24    [21847893]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
хранимая процедура не нужна, можно использовать union all
30 мар 19, 17:25    [21847895]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
вот пример запроса
select cast('<?xml version="1.0" encoding="Windows-1251" ?>' as varchar(1000))
from RDB$DATABASE
union all
select cast('<root day="'||c.FULL_DATE||'" shift="'||s.NAME||'" filter="'||ef.NAME||'" >' as varchar(1000))
from RDB$DATABASE
join CALENDAR c on c.ID_DAY = :"Дата"
join SHIFTS s on s.ID_SH = :"Смена"
join EMPLOYEE_FILTER ef on ef.ID_F = :"Фильтр" 
union all
select cast('<nodes>' as varchar(1000))
from RDB$DATABASE
union all
select cast('  <node '||
                 'fio="'||(select OUT_STR from XML$FORMAT_STR(e.FULL_NAME))||'" '||
                 'rang="'||(select OUT_STR from XML$FORMAT_STR(e.RANG))||'" '||
                 'tab="'||(select OUT_STR from XML$FORMAT_STR(e.TABEL))||'" '||
                 'dep="'||(select OUT_STR from XML$FORMAT_STR(coalesce((select NEW_NAME from TABEL$GET_FULL_DEP(eh.ID_EG, null, 0)),'')))||'" '||
                 'wtt="'||(select OUT_STR from XML$FORMAT_STR(wtt.NAME))||'" '||
                 'dur="'||cast(coalesce(fi.CALC_INTERVAL,0) as numeric(15,4))||'" />' as varchar(1000))
from EMPLOYEE e
join TABEL$EMPLOYEE_HISTORY eh on eh.ID_EMP = e.ID_EMP and eh.ACTUAL = 1 
join EMPLOYEE_FILTERED ef on ef.ID_EMP = e.ID_EMP and ef.ID_F = :"Фильтр"
join TABEL$FORECAST fc on fc.ID_EMP = e.ID_EMP
                      and fc.ID_DAY = :"Дата"
                      and fc.ID_TF = (select ID_TF from TABEL$GET_LAST_DOC(:"Дата", e.ID_EMP, 1))
join TABEL$FORECAST_INTERVALS fi on fi.ID_TF = fc.ID_TF
join TABEL$WORK_TIME_TYPES wtt on wtt.ID_WTT = fi.ID_WTT and wtt.ON_TER = 1
join TABEL$SHIFT_INTERVALS si on si.ID_SI = fi.ID_SI and si.ID_SH = :"Смена"
union all
select cast('</nodes>' as varchar(1000))
from RDB$DATABASE
union all
select cast('</root>' as varchar(1000))
from RDB$DATABASE
30 мар 19, 17:29    [21847899]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Dimitry Sibiryakov
Member

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

superspy2019
Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается,
если параллельная транзакция не была отменена по истечению таймаута.

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

Posted via ActualForum NNTP Server 1.5

30 мар 19, 17:46    [21847903]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9393
H5N1
superspy2019
Не знаю, с чего вы взяли, что я пришел сюда что-то показывать. Я пришел за умным советом. А вы, батенька, даете ужасные советы и пытаетесь троллить, выводя меня на эмоции.

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


ну не всем и не всегда. Только когда упёртные попадаются.
И вообще чего это ты в чужой огород зашёл? Слово Оракуль что-ли увидел? Так его вроде здесь не ругают.

H5N1
в запрос вникать лень, но на счет тразакции учти, фб не оракл. read committed там не гарантирует консистентного набора. 1 или 4 запроса вернут кашу с одинаковой вероятностью. судя по всему тебе нужна snapshot транзакция и 4 запроса в рамках снепшот транзакции


Во-первых в 4.0 read committed уже выдаёт согласованный результат на уровне запроса
Во-вторых ничего страшного в shapshot транзакции нет, если её не держать активной часами.
30 мар 19, 17:46    [21847904]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON
30 мар 19, 18:00    [21847912]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1319
Симонов Денис
superspy2019,

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON

Думаю вариант
4-ре select запроса (по одному на каждую таблицу)
возможно что и получится
30 мар 19, 18:07    [21847916]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

ну всякие ORM в большинстве случаев выбирает 2-ой, если только не используется отложенная загрузка свойств
30 мар 19, 18:10    [21847918]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
vvvait
вот пример запроса


Спасибо великое! Попробовал на примере for select в лоб составлять xml - крайне утомительно писать и еще более утомительно добиться потом валидации
30 мар 19, 18:16    [21847919]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Симонов Денис
superspy2019,

у тебя есть следующие варианты:

- взять готовую ORM (там всё за тебя уже сделано) и научиться работать с ней
- один большой select запрос, результат которого надо самостоятельно распихивать по коллекциям сущностей (делать ORM самому)
- много select запросов в snapshot в snapshot транзакции с распихиванием результатов в коллекции сущностей
- собирать JSON/XML на сервере и передавать как BLOB

Последнее кстати не так уж сложно сделать. Я в качестве эксперимента собирал UDR которая результат запроса закатывала в JSON


Да, спасибо, я склоняюсь больше к селектам, обернутым в снапшот. Оно хотя бы будет человечески выглядеть в результате
30 мар 19, 18:19    [21847920]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

ну его этот xml, уж лучше json
30 мар 19, 18:26    [21847924]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
superspy2019
Member

Откуда:
Сообщений: 31
Dimitry Sibiryakov
superspy2019
Вы совершенно забыли о том, что в режиме No_Record_Version + Wait исключение вызывается,
если параллельная транзакция не была отменена по истечению таймаута.

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


Уважаемый, фраза "если параллельная транзакция не была отменена по истечению таймаута" эквивалентна фразе "параллельная транзакция закоммитила изменения". У меня стойкое ощущение, что вы не воспринимаете параллельную работу многих потоков в БД как необходимость. При плотных update по таблице с какой-нибудь статистикой вы не сможете нормально выполнить ожидающий read_committed. У вас будет альтернатива в виде использования snapshot или более строгого уровня изоляции, либо более оптимального способа read_committed + rec_version - но он станет грубейшей ошибкой при чтении более 1 таблицы в одной транзакции, как вы это предлагали в ваших лучших традициях индусской практики ранее.
30 мар 19, 18:27    [21847925]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
Симонов Денис
Member

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

он никогда такого не предлагал. Более того он обычно советует везде и всегда использовать snapshot, а про существование RC вообще забыть.
30 мар 19, 18:40    [21847929]     Ответить | Цитировать Сообщить модератору
 Re: Запрос иерархических структур в FB 2.5  [new]
vvvait
Member

Откуда:
Сообщений: 70
Симонов Денис, json хуже, там запятые ставить нужно, хотя в новых версиях можно и в конце перечисления запятую ставить.
XML лучше тем, что потом можно шаблоном крутить как угодно и агрегаты посчитать и группировки с сортировками на клиенте, чтобы сервер разгрузить.
30 мар 19, 18:53    [21847937]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить