Nie jestem pewien, czy oryginalny nadawca nadal to monitoruje, ale i tak zadam to pytanie.
Pierwotny post zażądał, aby móc:
Aby automatycznie „zablokować” bieżącą procedurę, z którą pracujesz, nikt inny w zespole nie może wprowadzać w niej zmian, dopóki nie skończysz.
Być może problemem jest tutaj bardziej paradygmat programistyczny niż niezdolność produktu do „zablokowania” zapisanego procesu. Ilekroć słyszę „Chcę to zablokować, aby nikt inny tego nie zmienił”, od razu mam wrażenie, że ludzie dzielą schemat i wszyscy rozwijają się w tej samej przestrzeni.
Jeśli tak jest, dlaczego po prostu nie pozwolić każdemu mieć swój własny schemat z kopią modelu danych? Mam na myśli serio ludzie, stworzenie innego schematu nic nie "kosztuje". W ten sposób każdy programista może wprowadzać zmiany, dopóki nie staną się niebieskie na twarzy, nie wpływając na nikogo innego.
Inną sztuczką, którą stosowałem w przeszłości (w małych zespołach), kiedy nie było możliwe, aby każdy programista miał własną kopię danych ze względu na rozmiar, było posiadanie głównego schematu ze wszystkimi tabelami i kodem w nim, z publicznymi synonimami wskazującymi na to wszystko. Następnie, jeśli programista chce pracować nad przechowywanym procesem, po prostu tworzy go w swoim schemat. W ten sposób rozwiązanie Oracle odnajduje ją jako pierwszą, a nie kopię w schemacie głównym, umożliwiając im testowanie kodu bez wpływu na innych. To ma swoje wady, ale to był bardzo specyficzny przypadek, w którym mogliśmy z nimi żyć. Oczywiście NIGDY nie zaimplementowałbym czegoś takiego w produkcji.
Co do drugiego wymagania:
Aby automatycznie wysyłać zmiany wprowadzone w procedurze składowanej, w bazie danych anOracle, do repozytorium Subversion, CVS,...
Byłbym zaskoczony, gdybym znalazł narzędzia wystarczająco inteligentne, aby to zrobić (być może okazja :). Musiałby połączyć się z bazą danych, przeszukać słownik danych (USER_SOURCE) i wyciągnąć powiązany tekst. Wysokie zapotrzebowanie na systemy kontroli źródła, które są prawie powszechnie oparte na plikach.
