Tak jak obiecałem w opisie ustawiania ograniczeń teraz pokażę jak zdjąć limit ze skrzynki.

Kasowanie wygląda podobnie jak zmiana wielkości tyle, że ustawiamy rozmiar kwoty na wartość none:

cyradm -user cyrus localhost
localhost> listquota user/jaqb
 STORAGE 37094/40960 (90.5615234375%)
localhost> setquota user/jaqb none
remove quota
localhost> listquota user/jaqb
  /
localhost> quit

Jak widać ograniczenie zniknęło.

Miałem ciekawy przypadek błędu w repozytorium. Od razu powiem, że bez kopi zapasowej nie udało by mi się go rozwiązać.

Kopia robocza na jednym komputerze - wszystko działa (latami). Po jakimś czasie zachciało mi się (akurat - po prostu musiałem) w nim grzebnąć, ale już na nowym sprzęcie i ... klops. Okazało się, że repozytorium jest uszkodzone, co gorsza, jak się później okazało, już na wersji 2 (błąd dysku ???).

Komunikaty błędu miałem różne. Komenda svn pokazywała:

svn: REPORT of '/svnprv/reponame/!svn/vcc/default': Could not read \
 chunk size: connection was closed by server (http://localhost)

w error_log apache'a było:

[error] [client 127.0.0.1] Provider encountered an error while \
 streaming a REPORT response.  [500, #0]
[error] [client 127.0.0.1] A failure occurred while driving \
 the update report editor  [500, #160004]

a polecenie svnadmin verify reponame zwracało:

svnadmin: Checksum mismatch while reading representation:
   expected:  10b6f87d95a8283b4dc96607a662c4de
     actual:  1865015a5837bc21ea73397ee68e1c44

Po przejrzeniu backup'ów (makaronizm, ale "kopia zapasowa" jest taka długa...) znalazłem taki który miał poprawnie zapisaną wersję drugą - z przed 2 lat! W ten sposób posunąłem się o 400% (z wersji 1 do 4 ;-) do pełni szczęścia trochę brakuje...

Niby coś-tam działało, bo WebSVN ładnie pokazywał historie i doszedłem do tego, że mogę ściągać diff'y między różnymi wersjami, np.:

svn di http://localhost/svn/reponame@7 \
       http://localhost/svn/reponame@15

W ten sposób dowiedziałem się, że tylko wersja 2 jest uszkodzona. Niestety próby odzyskania reszty danych z bieżącego repozytorium nie dawały pozytywnych rezultatów (testowałem na różnych wersjach):

svnadmin dump -r3 reponame
svnadmin: Checksum mismatch while reading representation:
   expected:  959148e046aafa5f51db215c9ee0796d
     actual:  98824bfc23034f920d603d42a0810843

Oczywiście działało dla wersji 0 i 1. Kluczem okazał się przełącznik --incremental !

svnadmin dump -r3 --incremental reponame
* Dumped revision 3.

Teraz już poszło gładko. Trzeba założyć nowe repozytorium i załadować do niego dane z kopii (była spakowana bzip2):

svnadmin create reponame-new
bzcat reponame-2011-09-25.dump.bz2 | svnadmin load reponame-new
...
------- Committed revision 4 >>>

ustalić numer ostatniej wersji, powiedzmy 45 (żeby nie było równo) i wtedy (jak widać wersję 4 już miałem):

for x in `seq 5 45` ; do
    svnadmin dump --incremental -r $x reponame \
   | svnadmin load reponame-new;
done

... no trochę to trwało, ale za to pełen sukces.

Teraz wystarczy skasować stare i zmienić nazwę "nowego":

rm -rf reponam
mv reponame-new reponame

Ładowane dane były do pustego repozytorium, więc UUID się nie zmienił.

Teraz trzeba poprawić skrypt, żeby po pierwsze wychwytywał błędy przy robieniu zrzutu (dump) i może dodatkowo wykonywał jeszcze zrzut ostatnich np. 10 wersji...

Szukając narzędzi do projektowania baz w PostgreSQL'u natknąłem się na program do tworzenia aplikacji WaveMaker.

Wygląda przyzwoicie i jest OpenSource. Standardowo działa także z bazą PostgreSQL. Nie mam teraz czasu mu się dokładnie przyjrzeć i potestować, ale może kiedyś się przyda.

Potrzebowałem podać do serwisu www pozycję mojego stacjonarnego (oczywiście laptop, tutaj w znaczeniu nie telefon komórkowy) komputera. Innym zastosowaniem może być testowanie (wcale nie oszukiwanie) działania stron www z geo-lokalizacją.

Metoda jest prosta. Trzeba przygotować plik (niech będzie lokalizacja.json) zawierający pożądane współrzędne w postaci:

{
    "status": "OK",
    "accuracy": 10.0,
    "location": {
        "lat": 54.560,
        "lng": 18.430,
        "latitude": 54.560,
        "longitude": 18.430,
        "accuracy": 10.0
    }
}

Następnie taki plik trzeba dopisać nową wpis do konfiguracji, zgodnie z opisem. W moim przykładzie parametr o nazwie geo.wifi.uri powinien mieć wartość file:///home/jaqb/lokalizacja.json.

Gotowiec jak wystawiać faktury pro forma trochę niżej. Najpierw poznęcam się nad interfejsem programu.

Jak nie wystawiać faktur pro forma

Wydrukowanie faktury pro forma w programie Symfonia jest dość dobrze ukryte przed użytkownikiem. Aby wystawić fakturę pro forma w dziwny-i-dziurawiący-numerację sposób trzeba zacząć tworzyć fakturę, ale jej nie wystawiać, tylko wcisnąć "Drukuj" w prawym dolnym rogu okna. na okienku dialogowym drukowania trzeba wskazać dodatkowy napis do zamieszczenia na dokumencie. Do wyboru jest m.in. Test i ProForma. Tak przygotowana (nie wolno jej wystawić - musi być w Buforze) faktura dostaje swój numer i czeka na lepsze czasy.

W idealnym przypadku klient w końcu się zjawi, modlimy się (do swojego i kilku innych Bogów), żeby to było w tym samym miesiącu. Wtedy można wreszcie wystawić czekający dokument. Problem będzie gdy wystawimy fakturę pod koniec miesiąca, a klient się zjawi po np dwóch tygodniach i już numer się nie będzie zgadzał (jeżeli w numerze mamy miesiąc), a jak tym miesiącem będzie grudzień ...

W mniej idealnym przypadku klient się nie zjawi. Wtedy wystarczy anulować dokument - powstaje dziura w numeracji. Księgowa, a potem urząd skarbowy na pewno się ucieszą z takiego obrotu sprawy. Niby nie ma obowiązku nadawania ciągłej numeracji, ale ...

Teraz do rzeczy.

Sensowny sposób wystawiania faktur pro forma opisał dawno temu niejaki "robert":

<ciach>

Według sage proforma jest raczej zamówieniem obcym. Oto sposób na dodanie takiego dokumentu:
Należy zdefiniować nowy typ dokumentu o charakterze "Zamówienie Obce" i nazwać go Faktura Pro Forma. Dla utworzonego typu dokumentu na zwykłych zasadach stworzyć odpowiedni szablon numeracji.
Na podstawie wystawianych Faktur Pro Forma można następnie tworzyć dokumenty sprzedaży. Podczas ich wystawiania można dokonać zmian, za wyjątkiem zmiany nabywcy i dodania nowych towarów lub zwiększenia ich ilości.
Zwiększenia ilości lub uzupełnienia o nowe towary należy dokonać edytując dokument Pro Forma przed przystąpieniem do wystawiania dokumentu sprzedaży.

</ciach>

I to faktycznie się sprawdza. Faktur możemy wystawiać do woli. Mają zachowaną numerację niezależną od normalnych (faktura pro forma nie jest dokumentem księgowym) faktur. Na jej podstawie można szybko wystawić fakturę sprzedaży. Z bliżej nieznanych przyczyn ta metoda nie jest promowana przez producenta - może za prosta?