03:01 @duxet | 2014/11/11 02:59:14 [error] 7464#1408: *21 FastCGI sent in stderr: "PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 130968 bytes) in C:\dev\git\lara\vendor\jenssegers\mongodb\src\Jenssegers\Mongodb\Model.php on line 329" while reading response header from upstream, client: 127.0.0.1, server: strimoid.dev, request: "GET /api/v1/entries/Hn2pcJ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "strimoid.dev"
| grep "mongodb"
PHP Fatal error: Mongodb
@gethiox: strimoid jest produkowany na windowsie... teraz już rozumiem czemu działa jak działa i wygląda jak wygląda...
Panowie @gethiox: @akerro: wy sie odpierdolcie od mongo. fakt faktem duxet sie nie zawsze obnosi intelektem i doswiadczeniem w kwestiach pchania swiezych wersji, ale samo mongo jest duzo wygodniejsze do zastosowan takich jakie ten portal. sam używam w kilku srodowiskach produkcyjnych mongo, najwieksze ma ponad 3.5tb w 3 replikach po 3 shardy i nie wyobrazam sobie tego ani przenosic ani utrzymywac na sqlowym srodowisku. specyfika struktur danych spowodowala by gigantyczną komplikacje relacyjnego systemu: dupikację danych albo masę relacji i tabel pomocniczych. w kazdym razie w efekcie dzialaloby to wolniej niz na mongo, które wbrew pozorom głupie i wolne nie jest.
jeszcze pijąc do @akerro: pierdolisz pan o 7minutach na konfiguracje postgresa (taaa, jasne, fine-tuning duzych postgresqli to godziny analizy, ale cicho dziwki, bo mamy wykopowego specjaliste za 15k) a faktyczny poprawny fine tuning mongo jest duzo bardziej skomplikowany, szczegolnie w srodowiskach z shardami. wtedy trzeba pilnowac indeksów zarówno pod kątem optymalizacji zapytan jak i samego shardowania, zeby dane byly rozlozone równomiernie na kazdej partycji.
@Wojnar: da się, spytaj sie gynavela czy jak mu tam - ma windę z osobną vmką linuksową w trybie seamless. sam takiego potworka bym nie uzywal, ale każdemu według potrzeb. sam portal smiga na linuxie, bo to jedyna słuszna platforma, ale od srodowisk testowych i deweloperskich wara.
@zryty_beret: dotnet to potwór, nieudolna próba microsoftu na przepchniecie zamiennika javy. pamiętam buledópy jak wersje kolejne 2, 2.x 3, 3.x kompletnie rozdupcaly kompatyilnosc wstecz, dodawaly pierdyliard nowych kontrolek. kazda aplikacja dzialala inaczej, wygladala inaczej. istny koszmar.
@zskk: gupi jesteś i tyle, zabiłeś wątek teraz :<
koniec z nami, nie rozmawiajmy więcej na ten temat.
@Wojnar: da się, spytaj sie gynavela czy jak mu tam - ma windę z osobną vmką linuksową
lol, jak można pracować na Linux? Zapytaj developerów Linuxa jak im się to udaje, ale durny argument. GC spędził połowę życia robiąc RE Windowsa, więc jak inaczej mógłby to robić jak nie na windowsie?
@akerro: no chyba w zla strone odbijasz. wlasnie to przekazałem swoją wypowiedzią - kazdy swoje srodowisko pracy dobiera pod siebie. czytanie ze zrozumieniem :P
@zskk: my tu się śmiejemy i robimy jakiś sztuczny tłum na portalu a tu przychodzi jakieś... nie wiadomo co i psuje całą zabawę...
@zskk: Średnim, ma swoje minusy. To wasze porównanie SQL do NoSQL jest jak porównywanie czołu do karetki. Obydwoje są pojazdami i tyle je łączy. Z tym, że SQL ma znacznie większe pole do zastosowań niż mongo. Jak ktoś twierdzi inaczej, znaczy, że mało dziwnych projektów w życiu kodował :P
@Wojnar: czy ja wiem. mongiem da sie zastąpic praktycznie wszystkie sqle (poza transakcjami) 1:1 uzywając twardego schema dokumentow i zastosowaniem odpowiednich indeksów. w drugą stronę już niekoniecznie... aczkolwiek faktycznie to porównywanie z dupy jest. wiadomo, że dobrze zrobione schema sql jest nie do pokonania wydajnosciowo