Python-сообщество

Мне, например, очень бы не помешало.
Нужно нам использовать уникальные числовые ключи, а primary key их сделать нельзя. И при запросе генерировать тоже нельзя - во время заполнения новой формы юзер уже желает видеть ее номер. Если серии номеров с “дырками” - не беда. Лишь бы шли в возрастающем порядке.

Другое дело, что MSSQL (гадость та еще, но мы привязаны к backend) не позволяет делать генераторы.
Т.е. у него есть uniqueidentifier - но это GUID. А пользователи хотят видеть простое инкрементирующееся число. Его легче прочитать и очевидно, что если число больше - значит оно новее.
Вот и извращаемся с несколькими таблицами по одному IDENTITY в каждой - вместо генераторов.
Неприятно до омерзения.

Андрей Светлов
Нужно нам использовать уникальные числовые ключи, а primary key их сделать нельзя. И при запросе генерировать тоже нельзя - во время заполнения новой формы юзер уже желает видеть ее номер. Если серии номеров с “дырками” - не беда. Лишь бы шли в возрастающем порядке.

У вас нет сервера приложений? двухзвенка?

Андрей Светлов
А здесь опять сложно.
Два с половиной звена.
И понемногу перемещаем нужный код в серверную часть.

Так быстрее получается сделать что-то работающее.

Есть давняя история.
Была команда, которая собиралась сделать все-все правильно. Работала год. По их словам сделала прекрасную архитектуру, только вот конкретные применения были невозможны - ибо неуспели. Думали о высоком и о вечном. Я это все воспроизвожу в пересказе, т.к. в те времена о данном проекте ничего не слышал, а до настоящего времени даже в codebase практически ничего не осталось. Т.е. лежат в svn какие-то заброшенные проекты, но я их предметно не изучал.

Так вот, когда у деньгодавца терпение окончательно иссякло и на вопрос: когда же, наконец, был получен невразумительный ответ - старая команда была в основном разогнана. Новые люди собрали за полгода нечто вполне работающее, а потом уже и я подключился.

И, думаю, не самое плохое решение было. Т.е. вижу много ляпов и большая часть моей работы в данном проекте заключается в борьбе с ними. Миграция далеко не всегда безболезненная, и если бы сразу делали “правильно” - жить было бы легче. Но с другой стороны - система работает и уже приносит деньги (против такого аргумента возразить трудно). Кроме того только после запуска в эксплуатацию становятся видны настоящие требования. Так, многие из тогдашних придумок умерли за ненужностью, зато появились новые - и адекватные.

Конечно, будь моя воля - строил бы с самого начала все немного иначе. Есть очевидные вещи, которые делать нельзя никогда - и их трудно искоренять. Зато получаю бесценный опыт “живого глубокого рефакторинга”.

Что касается именно темы вопроса - можно эту штуку на серверную часть перенести, и не сильно долго делать-то. Просто это - далеко не самый главный приоритет.

Кстати, недавно для себя обнаружил, что с win64 у Питона - полная задница. Т.е. он есть - но поддержки setuptools/distutils для него совсем нет. Соответственно даже из исходников библиотеки по setup install не собираются. Встал вопрос о миграции нашего софта. Я, конечно же, с помощью какой-то матери все склеил вместе на отдельно взятой машине. Но в единый процесс билда мое творчество не вписывается. Есть шанс, что появится возможность вложить свои пять копеек в славное дело open source.
Питон 2.5, ограничения опять же по backend, на шестерке не пробовал. Если 2.6 все умеет - расскажите, научу и пятерку. Но - сильно сомнительно, setuptools то брал последний.

Андрей Светлов
А здесь опять сложно…

Спасибо. Интересно. Прямо “Долгий путь к XP в лицах” :)

PooH
Прошу прощения, просто из любопытства, а зачем вам на клиенте знать значение генератора?

Если запись идентифицируется только по ID, то при inserte новой записи уже надо этот ID знать. Чтобы перейти c def New на def View. Во-вторых, генераторы в FireBird используются не только для подстановки ID через триггер. Это самостоятельная штука, и его можно использовать, к примеру, для генерации уникальных страховых номеров