atarionline.pl Development ;) ATARIONLINE.PL! - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorwieczor
    • CommentTime7 Jan 2020
     
    Usunięcie komentarzy zburzy spójność danych, bo je utracimy :) Natomiast raczej na pewno nie rozwiąże to problemu.
    • 2: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @wieczor no bez jaj ;D ciekawiło mnie czy jakby on znikł z komentarzy to wciąż by się pojawiał jako popsujka.

    Na razie z dużym buforem, nie udaje mi się wywołać 404, ale może to kwestia czasu, zobaczymy.

    //ob_start();
    ob_start(null, 1600000);


    EDIT: jednak w "Rozmawiali" się właśnie pojawił

    /gfx/index.php?subaction=showfull&id=1386444009&archive=&start_from=0&ucat=5&ct=wywiady


    ------------------------

    OK. To ja już nie mam pomysłu, w sumie bufor obejmuje całość strony nie tylko nowinkę. Można by go jeszcze zwiększyć.

    Zwiększam go ostatni raz. I jak złapię uszkodzony link to wycofam zmianę i składam broń :]

    Mam wrażenie, że z ustawionym buforem AOL działa szybciej a popsute linki pojawiają się rzadziej, ale to może być po prostu wrażenie.
    • 3: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    OK. Oficjalnie muszę uznać się za pokonanego :>

    Jestem przekonany, że problem wynika z kombinowania z buforem ale nie umiem nad nim zapanować. Ustawienie go na duży rozmiar też nie rozwiązuje problemu.

    Wycofuję tę zmianę.

    Jeżeli jeszcze będę się bawił to lokalnie na swoim komputerze. W tej aplikacji cache nie do końca jest tym co nazwa sugeruje a bawiąc się nim "na żywca" można po prostu popsuć portal.
    • 4:
       
      CommentAuthorKaz
    • CommentTime7 Jan 2020
     
    OK. Ja dopiero siadłem przed kompem, więc jak mniemam, już nie dodawać nowinki testowej?
    • 5:
       
      CommentAuthorDracon
    • CommentTime7 Jan 2020
     
    @zbyti:
    I tak Twoje próby są docenione. Czy będziesz jeszcze próbował "reanimować" A.D.D.Ę ?
    • 6: CommentAuthormav
    • CommentTime7 Jan 2020
     
    Może to nie do końca kod jest winny, tylko kombinacja samego kodu i wykorzystywanej wersji PHP na serwerze? Może jest jakiś bug, który jest załatany w nowszych wersjach PHP?
    Oczywiście nowsza wersja PHP może też popsuć zupełnie co innego ;)
    • 7: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @Kaz nie, nie ma już potrzeby dodana nowinki. Aktualnie nie ma na serwerze innych moich zmian po za podmianą polskich znaków z windowsowego kodowania na unicode w index.php. Będę jeszcze działał ale lokalnie na swoim kompie bo chcę obadać poważniejsze zmiany i nie chcę też nikogo fatygować w tym czasie.

    @Dracon dzieki ;) Niestety albo nie widzę albo w miejscu do którego mam dostęp kod ADDA nie leży nawet jako archiwum. Nie mam dostępu do hostingu więc nie wiem co aktualnie jest podpięte pod subdomenę adda.atarionline.pl i czy są jeszcze jakieś serwery kupione.

    @mav też może być tak jak piszesz. Fajnie by było jak by ktoś z dokładnością co do roku pamiętał kiedy te 404 zaczęło się pojawiać.

    Szukając takich błędów można zostać wyznawcą Kultu Cargo i nabrać przeświadczenia, że 404 leci dokładnie wtedy kiedy ktoś otwiera drzwi w serwerowni :D
    • 8: CommentAuthorbruno_j
    • CommentTime7 Jan 2020 zmieniony
     
    @zbyti będąc posiadaczem Atari z magnetofonem można było dojść do podobnych wniosków. Brak związku pomiędzy sąsiadem trzaskającym drzwiami dwa piętra wyżej, a tym że program znów się nie wgrał, wykazano stosunkowo niedawno znajdując błędy w procedurach systemowych.
    Podsumowując, kulty cargo nam nie straszne :)
    • 9: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @bruno_j coś tam było że magia ma być nieodróżnialna od bardzo zaawansowanej techniki?

    Dobra, przyszedł mi do głowy oczywisty pomysł jak sprawdzić czy plik w cache jest zdrowy czy nie i właśnie nadarzyła się okazja.

    W momencie wystąpienia błędu, np. dla ostatnich nowinek w menu wystarczy puknąć pod odpowiedni adres np.:

    atarionline.pl/v01/_cache/cn-news-0.txt

    Wygląda, że w tej kwestii się myliłem i to co oceniłem na 1% ma miejsce ;) błąd jest przy tworzeniu a nie przy wyświetlaniu.

    Czyli wracamy do pierwszego założenia przyczyny błędu, pliku cached-cn-content.inc

    Także jr. podejmuję trop ;) musi być coś z buforem i śmieciem w pamięci bo inaczej skąd się brał zilog79 jako część popsutego linku?

    Walnięty plik w załączniku. Dla porównania wrzucam też zdrowy i właśnie chwycony, jeszcze cieplutki zilog79 :]

    EDIT: w załączniku udało mi się chwycić dziś chyba wszystkie warianty popsujek jakie widziałem przez ostatnie 2 dni.
    • 10:
       
      CommentAuthorKaz
    • CommentTime7 Jan 2020 zmieniony
     
    Widziałem newsa z roku 2037:

    Niejaki Zbyti opublikował nowoczesną w formie powieść kryminalną pod tytułem "Na tropie tajemnic cache'a". Ma ona charakter autobiograficznych zapisków o zmaganiach Zbytiego z oprogramowaniem serwerowym serwisu AtariOnline.pl. Zmaganiach, które prowadził w latach 2019-2026, jeszcze przed swoim niespodziewanym znalezieniem się w odosobnionym środku dla nerwowo chorych. Tam przeżył przemianę, która pozwoliła mu zapomnieć o horrorze serwerów AtariOnline.pl i napisać spowiedź życia o poszukiwaniach błędów w strukturach starożytnego kodu. Ta prawie siedmiusetstronicowa powieść o przyczynach złego linkowania urasta tu do symbolicznych zmagań człowieka z komputerem i uzyskuje status klasyki literatury, nie tylko informatycznej i kryminalnej, ale również filozoficznej. To będzie hit zarówno literatury faktu, jak i prozy, a przecież i naukowcy na całym świecie rozpoczęli hurtowy zakup książki do bibliotek wydziałowych ze względu na walory naukowe pozycji! Bogactwo materiału faktograficznego gromadzonego latami w postaci plików serwera, a także głębia własnych przemyśleń autora pozwala wierzyć, że książka stanie się niekwestionowanym liderem sprzedaży we wszystkich księgarniach. Nie będziemy zdradzać zakończenia, czy po sześcioletnich mękach Zbytiego udało się osiągnąć rozwiązanie zagadek skryptów AtariOnline.pl, zostawiamy przyjemność lektury z poznania zakończenia czytelnikom serwisu "Detektyw". Wiemy tylko jedno - warto kupić i przeczytać!

    :D

    PS. A serio - fajnie opisujesz zmagania z tym błędem, brzmi to prawie jak opowiadanie i zacząłem w tym brać emocjonalny udział. Wbrew mojej woli poszukiwanie tego problemu mnie wciąga :). Stąd takie skojrzenie jak wyżej. Ktoś tak też zauważył u siebie?

    PS2. Astrofor - na razie nie wiem, gdzie jest baza ADDA. Może Zyga zarchiwizował i stąd w ogóle jej nie widać na serwerze.
    • 11: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @Kaz haha, dobre, normalnie: "story of my life" :D

    Wrzuć to na lubimyczytac.pl jako zajawkę i daj tę datę premiery co powyżej :D

    A tak na poważnie to też powiem, że:

    zilog79_WYTNIJ_TO@I_TO_TEZ_tlen.pl /

    taki ciąg znaków jest tylko w jednym miejscu na cały AOL, w _cache i podanym wcześniej newsie. Naprawdę to ciekawe dlaczego w powtarzających się wariantach popsujki pojawia się właśnie ten ciąg na setki artykułów i tysiące komentarzy :]
    • 12: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    A no to już wiem, dlaczego nigdzie nie widziałem polskich znaków w tych plikach Windows-1252... :D

    //----------------------------------
    // Some Special Chars
    //----------------------------------
    $HTML_SPECIAL_CHARS = Array ( // Master array replaced ALWAYS !!!
    '±' => '&#261',
    'æ' => '&#263',
    'ê' => '&#281',
    '³' => '&#322',
    'ñ' => '&#324',
    'ó' => '&#243',
    '¶' => '&#347',
    '¼' => '&#378',
    '¿' => '&#380',
    '¡' => '&#260',
    'Æ' => '&#262',
    'Ê' => '&#280',
    '£' => '&#321',
    'Ñ' => '&#323',
    'Ó' => '&#211',
    '¦' => '&#346',
    '¬' => '&#377',
    '¯' => '&#379',
    );
    • 13:
       
      CommentAuthorDracon
    • CommentTime7 Jan 2020
     

    Kaz:

    na razie nie wiem, gdzie jest baza ADDA. Może Zyga zarchiwizował i stąd w ogóle jej nie widać na serwerze.

    A ja wiem... że coś tam się gdzieś zachowało. :P
    Gratka dla archeologów netowych!
    ->link<-
    • 14: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    No to po dłuższej analizie kodu kolejne zmiany wrzucone na produkcyjny AOL do testów.

    W tych plikach co nałapałem widać prawidłowość psucia się linków, psuje się wszystko na lewo od index.php.

    Odnalazłem deklarację i inicjację zmiennej z której budowana jest ta część w miejscach używających *.tpl. Zrezygnowałem z warunku, także wartość jest zawsze pobierana z tablicy $_SERVER

    Aby można było obserwować w cache tą wartość podmieniłem zabity na sztywno tekst na wartość tej zmiennej w cached-cn-content.inc.

    Obserwujmy :]

    /aol/cn/inc/functions.inc.php
    //if($PHP_SELF == ""){ $PHP_SELF = $_SERVER["PHP_SELF"]; }
    $PHP_SELF = $_SERVER['PHP_SELF'];

    /aol/v01/include/cached-cn-content.inc
    //było
    $contentUrl = "";
    if(isset($_SERVER["QUERY_STRING"]))
    $contentUrl = "<!-- url: /v01/index.php".((strlen($_SERVER["QUERY_STRING"]) > 0)?("?".$_SERVER["QUERY_STRING"]):(""))." -->\n";

    //jest
    $contentUrl = "";
    if(isset($_SERVER["QUERY_STRING"]))
    $contentUrl = "<!-- url: $PHP_SELF".((strlen($_SERVER["QUERY_STRING"]) > 0)?("?".$_SERVER["QUERY_STRING"]):(""))." -->\n";

    Jeżeli teraz będą się psuć linki to będę już bardzo bliski "prawdy".
    • 15: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    HA! Ledwo skończyłem pisać i już widać, że błąd jest w tablicy $_SERVER (tylko jakim cudem?) bo w cache złapało się:

    <!-- url: /js/gfx/v01/gfx/zilog79_WYTNIJ_TO@I_TO_TEZ_tlen.pl /index.php?ct=katalog&sub=R&tg=Ringmaster -->

    To za moment zabiję pod tą zmienną na sztywno /v01/index.php i zobaczymy co dalej.

    ------------------------------------------------------------

    EDIT1:
    OK, teraz jest taka zmiana:

    /aol/cn/inc/functions.inc.php
    //if($PHP_SELF == ""){ $PHP_SELF = $_SERVER["PHP_SELF"]; }
    $PHP_SELF = "/v01/index.php";

    @Kaz ta zmiana mogła rozwalić działanie atarionline.pl/cn/ ale przejrzyj to trochę (a najlepiej sprawdź czy Ci wszystko działa), ja teraz będę patrzył czy wciąż psują się linki. Może dodaj i usuń art. oraz komentarz.

    EDIT2: na razie front cyka, cache poprawne, jeszcze żadnego popsutego linka w menu nowinek nie widziałem od 45 min.
    • 16: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    Ok, od 1.5h nie udało mi się złapać żadnego 404 (pomimo prób), wydaje się, że zabicie ścieżki na sztywno w odpowiednim miejscu rozwiązało ten problem.

    Teraz tylko niech @Kaz potwierdzi, że mu wszystko działa z pozycji administratora i szlus.

    Jeżeli w panelu admina CN będzie jakiś problem to jeszcze pokombinuję.
    • 17:
       
      CommentAuthorKaz
    • CommentTime7 Jan 2020
     

    Zbyti:

    eżeli w panelu admina CN będzie jakiś problem to jeszcze pokombinuję.


    Na razie żadnego problemu nie odnotowałem :) Aczkolwiek zrobiłem tylko pobieżny test - dodanie artka, włączenie, wyłączenie, sprawdzenie wyświetlania. Będę dalej obserwował.
    • 18: CommentAuthorzbyti
    • CommentTime7 Jan 2020
     
    @Kaz to CZYWAJ! :D Mi się przez już 2h nie udało przyłapać AOL na 404 a sprawdzam co parę min cache. Przed poprawką to potrafiłem w tym czasie złapać z naście 404. Na ten moment linki w klockach są ROCK SOLID ;)
    • 19:
       
      CommentAuthorKaz
    • CommentTime7 Jan 2020
     
    Spoko. Nie chcę na razie dziękować, żeby nie zapeszyć! :D
    Ale wiadomo... ozłocimy Cię i dostaniesz księżniczkę za żonę :P
    O połowie królestwa nawet nie myśl ;)
    • 20: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @Kaz a to będzie księżniczka z cyklu "zrób to sam" czyli dostanę żabę do całowania?

    Jeżeli się udało to zajęło mi to 3 popołudnia ;)

    Najbardziej w programowaniu wkurza mnie fakt, że jak już się zna rozwiązanie to się człowiek dziwi, że nie wpadł na to od razu... Wbrew pozorom nie łatwo było mi "od tyłu" dojść do tego miejsca tylko czytając kod bo ostatecznie nie postawiłem tego lokalnie, wbudowany w PHP serwer tego nie ogarnął.

    To $_SERVER było po za podejrzeniem, błąd tutaj nie powinien mieć miejsca.
    • 21: CommentAuthorjakubd
    • CommentTime7 Jan 2020
     
    Szybkie odświeżenie (mojej głównie) wiedzy o PHP:
    1. $_SERVER nie jest stałą, można ją nadpisać i pewnie to się dzieje gdzieś przypadkiem.
    2. PHP_SELF: Caveat: This is after URL rewrites (i.e. it's as seen by PHP, not necessarily the original call URL).
    Ale muszę powiedzieć, że podobnie jak Kaz zagryzam paznokcie :) Normalnie Literatura faktu :)
    • 22: CommentAuthorzbyti
    • CommentTime7 Jan 2020 zmieniony
     
    @jakubd dzięki za info, od prawie 3 lat nie dotykałem PHP, już wiele nie pamiętam ;) Mogę sprawdzić czy kod gdzieś jawnie coś z tym kombinuje. Tylko wtedy determinizm byłby chyba łatwiej zauważalny, no i skąd ten zilog79 wtedy?
    • 23:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020
     

    Dracon:

    A ja wiem... że coś tam się gdzieś zachowało. :P
    Gratka dla archeologów netowych!
    ->link<-


    Tak, Zbyti już podawał ten link i skomentowałem, że właśnie tam sporo materiału brakuje. Ale zawsze można coś tam zobaczyć, jakiego rodzaju dane gromadziliśmy.
    • 24: CommentAuthorNitro
    • CommentTime8 Jan 2020 zmieniony
     
    A może by po prostu chwilowo wyłączyć cache? Skoro powodowane problemy są większe niż niedogodność[te x s ładowania się strony].
    Nie znam stosu stony ale nowy PHP 7.x potrafi dać kopa 2-3x. które chwilowo zrekompensują ból.
    Finalnie konkretne przypadki spisać, bazę zamrozić, włączyć szczegółowe logowanie i prowadzić śledztwo na spokojnie u siebie na serwerze z porządnym debuggerem.
    Również w PHP nie siedzę więc to raczej moja ostatnia porada ale sporo takowych zagadek z gatunku beznadziejnych udało się rozwiązać u znajomych którzy lov levelem się brzydzili...
    Greets i życzę szybkiego rozwiązania problemu.
    • 25: CommentAuthorzbyti
    • CommentTime8 Jan 2020 zmieniony
     
    @Nitro

    1. Ten cache to jądro tego systemu! Pisałem, że nazwa myląca ;)

    2. Na serwerze jest PHP 7.0.X

    3. Ten system nie ma bazy danych, oparty jest na plikach.

    4. Dzięki za życzenia :) problem wydaje się rozwiązany.
    • 26:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020
     
    O cię kurka! Nawet Nitro się odezwał! :D
    Ostatnio oddzywają się na forum nawet takie osoby, które komentowały tu bardzo rzadko. Czy to jakieś postanowienia noworoczne, żeby na AOL napisać w nowym roku jakiś fajny komentarz? :D

    Nitro - nie zapomnij o naszych primaaprilisowych planach dla użytkowników forum :D
    • 27: CommentAuthorNitro
    • CommentTime8 Jan 2020 zmieniony
     
    @Kaz:
    :) Akurat obijam się dziś o sprawy webdevowe i jakimś trafem trafiłem i na AO :)
    @Zbyti:
    Jeśli działa to nic tylko pogratulować postawienia na nogi legacy systemu które mają swoje 'ciemne strony' na nogi. Jakby nadal się coś działo, to jestem nikim ale poradziłbym mój patent z zamrożeniem stanu systemu i śledztwie po nim co się dzieje nie tak. W międzyczasie ofcoz można jakimiś hackami przywracać stronę do działania
    • 28: CommentAuthorzbyti
    • CommentTime8 Jan 2020 zmieniony
     
    @Nitro oczywiście Twoja rada jest dobra. Po prostu z pewnych powodów jedyne na co mogłem sobie pozwolić na szybko to wbudowany w PHP serwer a on nie bardzo sobie poradził od kopa z tym kodem dlatego szukałem głownie na sucho, czytając, dopiero dziś się z tym kodem jakoś oswoiłem i zajarzyłem z grubsza jak to działa.

    Pomysł z szukaniem z podpiętym debuggerem jest dobry, tylko po za tym co napisałem wcześniej teraz nie miałem na to możliwości, a po drugie ciężko się zaczaić na coś gdy nie było do końca wiadomo gdzie powstaje a do tego potrafił błąd się nie pojawić nawet przy kilkudziesięciu odświeżeniach strony. @wieczor ponoć próbował swego czasu tej metody.

    Mam nadzieję, że linki nie będą się psuć a reszta w rękach @wieczora :]
    • 29: CommentAuthorastrofor
    • CommentTime8 Jan 2020
     
    Ja bym wszystkie linki sprawdzał i poprawial po zaladowaniu strony javascriptem, wyrazeniami regularnymi. W sensie gdyby nie bylo naprawione bo juz jest.
    Serio nie ma bazy datnych ? Straszny kosmos.
    Apropos galeri to obawiam sie ze odzyskanie danych do ADDA z webarchwe bedzie bardzo trudne, i pewnie w calosci niemozliwe.
    A wlasnie doszukalem sie ze gallery 3 ma wersje dzialajaca pod php7 i
    na githubie. Takze wpisuje to na kandydata do przyszlej wersji galeri.
    ->link<-
    • 30:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020 zmieniony
     

    Astrofor:

    Serio nie ma bazy datnych ? Straszny kosmos.


    Obecnie kosmos. A w 2003 roku rozmowa wyglądała tak:
    Zyga: co ma być na tej stronie?
    Kaz: właściwie tylko archiwum plików i od czasu do czasu notka, że dodałem pliki.
    Zyga: to nie potrzebujemy bazy danych, niech będzie maksymalnie proste.

    No co mogło pójść nie tak? :D

    Astrofor:

    A wlasnie doszukalem sie ze gallery 3 ma wersje dzialajaca pod php7


    Świetnie! Podpytam Zygę, gdzie w takim razie może być ADDA.
    • 31: CommentAuthorwieczor
    • CommentTime8 Jan 2020
     
    @zbyti Gratuluję :)

    A co do artykułów opartych na plikach - co może pójść nie tak? Wszystkie artykuły są w jednym pliku. Który sobie rośnie. Nie tak może pójść, że urośnie za bardzo i system może go nie czytać - ale to nie ten system i nie ten przypadek. Poszło nie tak, gdy przypuszczalnie nastąpiły kolidujące zapisy do pliku. Plik się uszkodzi w jednym miejscu i cały misterny plan w p.... :)
    • 32:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020
     
    Tak, ale plik urósł do niebotycznych rozmiarów dopiero, gdy się okazało, że napisałem tysiąc artykułów, a komentarzy do tego pojawiło się kilkadziesiąt tysięcy :D Wtedy posypało się pierwszy raz.
    • 33: CommentAuthorzbyti
    • CommentTime8 Jan 2020 zmieniony
     
    @wieczor - dziękuję! :]

    To powodzenia w spisaniu założeń nowego AOL, chyba, że już kodujesz to powodzenia w kodowaniu :)

    Jakbyś jeszcze nie startował to za około miesiąca do dwóch może też mógłbym się przyłączyć do prac? Zobaczy się...

    Kod obecnego AOL widziałem :> Przeczytałem sporo tego co jest w "v01" i niezły kawałek tego co jest w "cn" i mogę tylko powiedzieć, że za to, że od wielu lat zajmujesz się tym portalem, każdy narzekający na jego działanie na najbliższym zlocie powinien postawić Ci piwo! :D
    • 34: CommentAuthormav
    • CommentTime8 Jan 2020
     
    Z brakiem bazy danych popełniłem oniegdaj podobny błąd, jak stawiałem sobie swój "system" spisywania umów z klientami. A teraz klientów mocno przybyło, plików zrobiły się duże ilości i każdorazowe wyświetlanie listy przemiela wszystkie pliki...
    Ale korzystam z tego sam, więc to nie jest jakiś duży problem, choć kiedy tylko chcę jakieś nietypowe podsumowanie = zabawa z kodem.
    • 35:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020
     
    To tak wyjaśnię, że Wieczór tak od około 3-4 lat się opiekuje bieżącym działaniem serwisu (dobrze pamiętam Wieczór?).

    Wcześniej był to przez wiele lat Zyga (który obecnie też raz na ruski rok interweniuje). A do tego dołożyli swoje cegiełki Cosi, Paw, Kuba Husak. Jeżeli o kimś zapomniałem to z powodu sklerozy, a nie celowo.


    Wygląda, że na razie nie ma błędu 404, więc też się przyłączam do podziękowań i gratulacji za udane śledźtwo Zbyti :) Książki więc nie będzie :( :)
    • 36: CommentAuthorzbyti
    • CommentTime8 Jan 2020 zmieniony
     

    Kaz:

    Książki więc nie będzie :(

    No to akurat jest "plus ujemny" ;) "plus dodatni" jest taki, że pobytu w psychiatryku także nie będzie :D

    Za to ostała się recenzja książki z której za 17 lat mógłbym być dumny, więc co będę czkał, już jestem! :D
    • 37:
       
      CommentAuthorjhusak
    • CommentTime8 Jan 2020 zmieniony
     
    Co do bazy plikowej - podejrzewam, że gdyby to było na sql-u, to już 50 razy by się wywalało i trzeba by tabelki reperować.

    W przypadku plikowej bazy danych należy zadbać o locki przy zapisie do pliku, aby max jeden proces zapisywał. I gra gitara.
    • 38: CommentAuthorzbyti
    • CommentTime8 Jan 2020 zmieniony
     
    Może w nowym AOL @wieczor zdecyduje się na SQLite? Było by wygodnie archiwizować i nie trzeba by kolejnego serwera.

    Nawet też jest świetlana przyszłość dla tego rozwiązania :D

    SQLite developers pledge to keep it that way through at least the year 2050.

    W sumie po za pewnymi specyficznymi funkcjami to jak się używa ORM to zmiana bazy powinna być tylko zmianą drivera.
    • 39:
       
      CommentAuthorDracon
    • CommentTime8 Jan 2020 zmieniony
     
    Nie wiem jak Wy, ale ja uważam, że Zbytiego należałoby ozłocić. Sławetny tutejszy #404 itp. jak na razie u mnie nie występuje i nie wiem jak to się udało.
    Za to w/w jest skuteczny jak widać i dobrze rokuje na przyszłość. :)
    Duża doza wytrwałości i dociekliwości, wyniesiona, jak myślę, z pasji gry w szachy oraz z (zapewne) wykonywanej pracy, owocuje! ;)
    • 40: CommentAuthorwieczor
    • CommentTime9 Jan 2020 zmieniony
     

    jhusak:

    podejrzewam, że gdyby to było na sql-u, to już 50 razy by się wywalało i trzeba by tabelki reperować.


    Podejrzewam, że się mylisz :) To, wraz z koniecznością zakładania locków to już pieśń odległej przeszłości. Kiedyś istotnie był to problem.

    zbyti:

    Może w nowym AOL @wieczor zdecyduje się na SQLite? Było by wygodnie archiwizować i nie trzeba by kolejnego serwera.


    Ale nie ma potrzeby nowego serwera. Baza na SQL jest i działa. A backup jest banalny. Tylko portal jej nie używa a wyłącznie forum :) SQLite sprawdza się głównie przy niewielkich bazach danych, gdzie wykonuje się małe, proste operacje i nie za dużo. Stawia się go tam, gdzie z uwagi na warunki nie ma możliwości postawienia pełnego SQL-a lub nie ma takiej potrzeby - np. przy statystykach.
    • 41: CommentAuthorzbyti
    • CommentTime9 Jan 2020 zmieniony
     
    @wieczor no bez przesady z tą niewielkością ;)

    SQLite database files have a maximum size of about 140 TB. On a phone, the size of the storage (a few GB) will limit your database file size, while the memory size will limit how much data you can retrieve from a query.

    A tutaj performance ->link<-

    Wydaje mi się, że masz trochę stereotypową opinię na temat tej bazy.

    ---------------------------------------

    Na dziś dzień nowinki AOL mają niecałe 13 MB.

    ---------------------------------------

    Dla mnie MySQL i podobne do tego czym jest (i ma być) AOL to trochę przesada.

    @Dracon dzięki za laurkę ;)
    • 42: CommentAuthorwieczor
    • CommentTime9 Jan 2020
     
    Niekoniecznie :) Zwróć uwagę, że do dzisiaj AOL nie ma poprawnego wyszukiwania. Istotą są operacje jakie masz wykonać na danych a nie tylko ich rozmiar ;) Zresztą twórcy serwisu też się kierowali zasadą, że baza danych to przesada i wyszło co wyszło :) Głupi blog typu wordpress jest dziś oparty na bazie - bo to jest po prostu wygodniejsze. A MySQL jest raczej w sam raz - przynajmniej na razie. Postgress byłby przesadą.
    • 43: CommentAuthorzbyti
    • CommentTime9 Jan 2020 zmieniony
     
    No wiesz, wciąż nie wiem jakie masz założenia projektowe.

    Na AOL jakim jest na dziś SQLite było by OK.

    Np. z linku performace jaki dałem (a to osiągi wersji 2 nie 3):
    Test 5: 100 SELECTs on a string comparison
    BEGIN;
    SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one%';
    SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%two%';
    ... 96 lines omitted
    SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%ninety nine%';
    SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one hundred%';
    COMMIT;
    PostgreSQL: 13.409
    MySQL: 4.640
    SQLite 2.7.6: 3.362
    SQLite 2.7.6 (nosync): 3.372

    -----------------------------------

    Test 7: 5000 SELECTs with an index
    SELECT count(*), avg(b) FROM t2 WHERE b>=0 AND b<100;
    SELECT count(*), avg(b) FROM t2 WHERE b>=100 AND b<200;
    SELECT count(*), avg(b) FROM t2 WHERE b>=200 AND b<300;
    ... 4994 lines omitted
    SELECT count(*), avg(b) FROM t2 WHERE b>=499700 AND b<499800;
    SELECT count(*), avg(b) FROM t2 WHERE b>=499800 AND b<499900;
    SELECT count(*), avg(b) FROM t2 WHERE b>=499900 AND b<500000;
    PostgreSQL: 4.614
    MySQL: 1.270
    SQLite 2.7.6: 1.121
    SQLite 2.7.6 (nosync): 1.162


    -----------------------------------

    Test 9: 25000 UPDATEs with an index
    BEGIN;
    UPDATE t2 SET b=468026 WHERE a=1;
    UPDATE t2 SET b=121928 WHERE a=2;
    ... 24996 lines omitted
    UPDATE t2 SET b=35065 WHERE a=24999;
    UPDATE t2 SET b=347393 WHERE a=25000;
    COMMIT;
    PostgreSQL: 18.797
    MySQL: 8.134
    SQLite 2.7.6: 3.520
    SQLite 2.7.6 (nosync): 3.104

    Do tego jak wiesz, gdy użyjesz ORM to zawsze możesz zmienić bazę na dowolną inną wspieraną gdyby SQLite nie spełniło Twoich oczekiwań.

    A jak już byśmy chcieli być finezyjni to do AOL może pasuje bardziej NoSQL?

    Ale to wszystko gdybanie do póki nie ma spisanych założeń nowego AOL.

    No dobra, obiecuję nie proponować na przyszłość rozwiązań, skoro na Twojej głowie jest cały ten majdan to rób jak uważasz :)
    • 44:
       
      CommentAuthorKaz
    • CommentTime9 Jan 2020
     

    zbyti:

    Ale to wszystko gdybanie do póki nie ma spisanych założeń nowego AOL.


    Tobie zapewne chodzi o założenia techniczne. To z chęcią i ja bym je (z grubsza) poznał. Ja mam gdzieś zbunkrowane tylko założenia merytoryczne AOL - jakich funkcjonalności brakuje, jakie wymagają przebudowy (np. wprowadzanie danych do Biblioteki Atarowca), etc.
    • 45: CommentAuthorzbyti
    • CommentTime9 Jan 2020
     
    @Kaz no to wrzuć swój dokument bo technicznie (wiem, że prawdziwe relacje są inne) to Ty tu jesteś klientem a @wieczór i inni wykonawcą.

    Twój dokument to "wymagania biznesowe" z którego powinna powstać cała reszta.
    • 46:
       
      CommentAuthorKaz
    • CommentTime9 Jan 2020
     
    Na nieszczęście to nie jest "dokument", który rozumiem jako jednolity tekst, tylko zbiór różnych moich emaili do Zygi; plus dyskusja wewnętrzna redakcji o tym, co uważamy za ważne zmiany; plus to, co było postulowane / dyskutowane na forum; plus moje notatki pisemne. Wypadałoby kiedyś faktycznie doprowadzić to do formy jednego spisu podzielonego na rzeczy krytyczne, potrzebne oraz koncert życzeń :D
    • 47: CommentAuthorzbyti
    • CommentTime9 Jan 2020 zmieniony
     
    Przepraszam, że wracam jeszcze do tematu ale bardzo mnie ciekawi (takie kronikarskie zacięcie) od jak dawna to 404 było obserwowane?

    Posłużyłem się wyszukiwarką na forum i bezpośrednia wzmianka o 404 w artykułach datuje się na czerwiec 2019. Inne 404 to brakujące pliki więc nie ten case.

    Kod nie był dotykany od wiosny 2018, wiec jeżeli błąd jest dopiero od 2019 to problem jest po za kodem AOL, wtedy raczej jest po stronie OVH i ich stacku.

    Chociaż nie dam głowy bo czytając źródła widziałem (chyba, nie będę teraz jr. szukał bo usunąłem źródła) coś co wyglądało na próbę rozpoznania problemu, więc wtedy 404 datowało by się także przynajmniej na 2018.

    Ktoś mniej więcej pamięta?
    • 48: CommentAuthorwieczor
    • CommentTime9 Jan 2020
     
    Problem pojawił się w 2018 a kod był dotykany ostatnio w listopadzie 2018. Była wtedy przesiadka z PHP 5.3 etapami na 5.6 a potem 7.0, i dużo musiało być zmieniane z tego powodu.
    • 49: CommentAuthorzbyti
    • CommentTime9 Jan 2020 zmieniony
     
    @wieczor dzięki za info :]

    Z listopada to widziałem tylko glosuj.php reszta plików ma datę luty / kwiecień 2018 najpóźniej.

    Pytam bo ten "zilog79" mnie wciąż intryguje ;)
    • 50: CommentAuthorzbyti
    • CommentTime9 Jan 2020 zmieniony
     
    @wieczor patrz tutaj Random memory corruption with strings ->link<-

    24 hours later, on the other server, this error completely broke all websites:

    Warning: require(/srv_ssd/domains/website/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled-php): failed to open stream: No such file or directory in /srv_ssd/domains/website/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php

    As you can see, instead of including /srv_ssd/domains/website/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php the string was changed from a dot to a dash. Interestingly enough, this error appeared in all three projects running on the server, although each had its own (identical) version of smarty_internal_template.php - but maybe the PHP opcache caches them only once if they are all the same, even if they are in different directories.

    Kurcze jak to dziwnie znajomo wygląda :D

    require(/srv_ssd/domains/website/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled-php): failed to open stream: No such file or directory 

    Może w takim razie to nie być błąd w "naszym" kodzie, nie znalazłem nadpisywania (a wczoraj chwilę szukałem) $_SERVER["PHP_SELF"].

    Z resztą rozum podpowiada, że jak by coś było w "naszym" kodzie nadpisywane to problem byłby deterministyczny w sposób oczywisty.