Доброго дня ALL!

озадачили вот такой проблемой.
Есть PK: id_base integer, id_item bigint
надо сделать аналог autoincrement для поля id_item но нумерация должна идти в пределах id_base.

Судя по прочитанному такого в ASA нет (да и в других СУБД вряд-ли).
Значит надо самому эмулировать этот процесс.

Вопрос: КАК?

Главная особенность autoincrement в том что я могу вставлять записи не дожидаясь пока другой коннект даст commit (в случае rollback этой другой сессии просто будет дыра в id_item что не страшно).

Тесты с тригерами на вставку и select max(id_item) with (readuncommited) к успеху не привели - два коннекта получают одинаковые значения и торжественно вылетает PK is not unique

> Тебе нужно запихнуть вставку в цикл и вставлять до тех пор, пока не вставит.

Интересное решение.
Интересно, а на уровне тригерной логики такое провернуть реально?

PaulJBДля АСА 9 и выше (не знаю про более нижние версии) посмотрите в сторону
функции GET_IDENTITY()
Помню такое, что она резервирует ключ (хотя может и ошибаюсь) давно было.

Это работает и справедливо если у тебя ключ состоит только из autoincrement поля.

MasterZiv
> Тесты с тригерами на вставку и select max(id_item) with (readuncommited)
> к успеху не привели - два коннекта получают одинаковые значения и
> торжественно вылетает PK is not unique

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

Вот тут как раз мне нельзя поднимать уровень изоляции. Т.к. пока одна сессия вставляет (процес от миллисек до минуты) другая должна спокойно писать свои данные.
Повторю - поле autoincrement это позволяет (примерно я себе представляю алгоритм работы этого процесса - счетчик, но не вижу путей для его реализации собственными силами, т.к. я не могу менять измененный данные пока не пройдет commit).

Буду экспеерментировать с внешними процедурами ;(((

MasterZiv
v_smirnov пишет:

А это не значит обязательно, что другая сессия не вставит свои данные.
Она не сможет вставить конфликтующие данные.
И без повышения ничего работать не будет. Так что тут IDENTITY рулит.
Posted via ActualForum NNTP Server 1.4

Не забываем про условия моей задачи.
"In SQL Anywhere, the IDENTITY column and the AUTOINCREMENT default setting for a column are identical."
У меня ДВА поля в ключе и AUTOINCREMENT должен идти для каждого id_base свой!!!

Пока вопрос решается так:
Реализовали свой счетчик для такой таблицы + внешняя процедура со своим коннектом (и как следствие своей транзакцией).

Многократную вставку реализовать на тригерной логике похоже невозможно.

VolokolaНе совсем понятна задача.
В ASA10 в таблице добавил два поля, на каждое указал autoinrement и оба включил их первычный ключ.
Или нужно как то по другому?

PK: id_base integer, id_item bigint
надо сделать аналог autoincrement для поля id_item но нумерация должна идти в пределах id_base.

id_base константа для логической базы.
на одном сервере может быть несколько логических баз.
пример -
id_base = 2 - база №2. id_item - от 1 до ... в пределах id_base=2
id_base = 4 - база №4. id_item - от 1 до ... в пределах id_base=4

etc ...

antand
А новый ключ для каждой записи запрашивать через процедуру, которой передавать @id_base.
Процедура сделает типа:


Именно так и сделано (пулл id-ов) за исключением одного нюанса.
Процедура внешняя ...
Причина по которой процедура была вынесена за пределы СУБД проста - у нее (процедуры) в таком исполнении свои транзакции что немаловажно для решения задачи, а именно:
1. Вставка может идти как 1 сек так и несколько минут.
2. Если делать внетренней процедурой то после Update запись будет заблокирована на запись до завершения транзакции и как следствие другой коннект не сможет получить новый ид...
3. насколько я понял алгоритм работы - обновление счетчика autoincrement поля именно так и происходит, в своей транзакции (реализована внутренними средствами СУБД и аналог реализовать стандартными средствами похоже невозможно).

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


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

2 Volokola - использовать global autoincrement не хочу, не нравится мне. Для меня он имеет больше минусов чем плюсов ...

antandТогда можно поподробнее. Как у Вас организован это поток вставок?

Не у меня ;) ...
Алгоритм хитрый - внешний клиент начинает вставлять данные, при чем именно в момент вставки (тригером) принимается решение о дополнительной вставке в эту же таблицу. (пришла одна запись - сохранить как 2..3..N).

Т.е. если даже клиент скажет что у него всего 30 строк на вставку высчитать сколько это на самом деле не представляется возможным.

Такая логика, что поделать.
Либо переделывать ее (логику) либо внешняя функция (счетчик) в отдельной транзакции.