ah i was forget. we have in plan make freeware plugin to get this data readeable from admin panel. data will shown in columns in form. this will be our own data base manager :)
as i see i can add more fields or remove some current fileds without making changes in database (xx_pages.php). i don't need to insert or remove any symbols here like $ in old version. that's good :)
re: now it is too late to change direction especially that we are confident that this way is good.
With all due respect, Treewood, this is big BS. Everything can be changed, even now. RC1 is not a final. It should be tested, not put into live production. But that's not the top reason because of which it is BS. The real reason is that you didn't give us a chance to tell you our opinion (I did notice a poll about Mysql db but it was not targeted at us, experienced PHPers). You want us to co-develop QC: http://opensolution.org/Quick.Cms/forum/help-us-with-development-of-the-free-skins-plugins-etc,1954.html ...but you never gave us a chance to give you a feedback on another step towards RC1. I didn't see any preliminary version, not even a beta. You come with RC1 saying it cannot be changed anymore. ALL THE WHILE DB FORMAT CHANGES ALMOST EVERY YEAR, more or less.
You could be compared to an architect of a building not acknowledging the dangerous architecture but taking comfort in how quickly the lifts can go. If you want to get the QC evolving, you cannot say that it's only for small dealers of knick-knacks. I am saying it works for thousands of products and possibly a hundred-thousand of images (in the future).
I don't want to make a fork, nor I have time for it. I think I have informed about this new db format here a moth or two months ago, but cannot find the post [not sure, maybe it was an email to a buddy].
I cannot claim I've done my test, but as for json: on this page http://php.net/manual/en/function.serialize.php the anonymous guy claims: if you just want a way to store array as string, you should use "json_encode" and "json_decode" because: 1. json_encode + json_decode is much faster than serialize + unserialize 2. json format is readable 3. json format is smaller than serialized result
Next guy: I ran some benchmarks to see which is the faster, and, surprisingly, I found that serialize() is always between 46% and 96% SLOWER than json_encode(). So, if you don't need to serialize objects and have the json extension available, consider using it instead of serialize().
To sum it up: I bet if you do it the way I suggested (take away keys, store them in a .def.php file and serialize the sequential arrays with json) your results for json will be a bit better, if not much better than serializing the multi-dimensional array with keys. All the while it will be a readable format again, I guess. Especially if json places each sub-array in a multidimensional array on another line (I am not sure it does).
baron_jon - 20% is nothing? tell this to users that have big traffic. And yes adding new field is much much easier.
beholder - beta version was published to some developers over 20 developers, our commercial partners and json problem was mentioned too. We've talking about this data storage and after beta version from over 4 weeks.
But i suspect why u are so nervous ... you have many your paid plugins and you will need to change them... this is problem i suspect for you. We have the same problem and we are working on it lots of time but we believe the serialize way is much better. With all respect to you but next programmers will have much easier to modify database and i dont agree with you with that.
About json. Oh come on. Please check and after write. Without testing you publish only demagogy. We've tested it on QCMS. Json_encode is faster then serialize but ... unserialize is much faster then json_decode. what is more important in perfromance ... get data to show products, pages or saving data in admin panel?
Dont believe us? If you dont then read some prove here: http://www.php.net/manual/en/function.serialize.php#103761 "Even if serialize() has it's downfalls, unserialize() balances that out." and "Please take into consideration the difference between unserialize() and json_decode(). In every instance, unserialize() was always faster."
Another: http://www.php.net/manual/en/function.serialize.php#100602 - "and unserialize is 70% fast than json_decode."
But i have good news for you. To save and get data there is 2 functions in FlatFilesSerialize. Change first serialize to json_encode and save pages from admin list changing for example status of one page. Then you have all pages saved with json. After change function to get data to json_decode. Few more changes and after 15 minutes you have database in json format :)
If people will write to us after we will publish stable version ... GUYS WE HATE SERIALIZE then we will change to json format. No problem. And converter will be very very easy in use. Not like our old database converters. But json it will be 20-30% get data longer (our tests) from database then unserialize (depends of size of data, if size is bigger then unserialize is much faster as json, check below).
For example 2008 products in one file database (the same data): - standard format with $ - 2.93 MB - 2 files db and db_ext with full description - json format - 3.17 MB - serialize format - 3.34 MB - 170 KB (5%!!!) bigger then json
Performance (get data to array from whole file on my stand alone without load server becuase this server on os.org have big load and time generating is not objective): - unserialize - 0.0244050 sec - standard format - 0.0298212 sec - 2 files db and db_ext with full description, here script get only db products to array and get only 1 line from product db_ext to get product details - json_decode - 0.1237879 sec (5 x times slower then unserialize with this particular data).
Files to check: standard http://opensolution.org/_test/db-formats/db.txt http://opensolution.org/_test/db-formats/db_ext.txt
Performance ... get whole data to array and get product details with id 1000 (of course in standard method script get whole data from db.txt to array and only 1 line from db_ext.txt, in json and serialize script get whole data from one file with full descriptions etc):
Standard - http://opensolution.org/_test/db-formats/a2.php - avarage time 0.0259 Serialize - http://opensolution.org/_test/db-formats/b2.php - avarage time 0.0197 Json - http://opensolution.org/_test/db-formats/c2.php - avarage time 0.0849
Get code to check how it works here: http://opensolution.org/_test/db-formats/get-code.php
And finaly yes: serialize is faster then json and standard format, is easier to add field. Remember that b2 and c2 load WHOLE data of products not such like a2. If you want get whole data in a2 then performance will be near json method.
And yes! Memory usage is bigger but ... 2000 products is enought max. We designed script to max 1000 products. Standard server memory to script is 16 MB (but mosts server have larger memory limit like 64 or 128 MB). Then if someone will have 1000 products, 3000 files and 200 pages then script will be fine and faster then old one.
For example on this server: http://opensolution.org/_test/db-formats/b3.php - loads 16 000 products in time 0.177 sec ... 8 x data and 2 x slower then json! :)
We want do one exception to orders.php because you can have 10 000 orders. We will use serialize too but in slower but less memory usage way.
And final final... Standard wordpress without modifications gets 10-12 MB memory from server. Standard Quick.Cms v4.0-rc1 gets 0.7-0.8 MB!!! No comments about that for me. Faster 10 x in standard version and less memory usage even script have 1 000 pages then standard version of wordpress.
Ok that enought. I spend much time to write this and send you tests. If it is not enought then sorry i have no time more to convince you. Stay with your opinion as you wish.
ok, I take your comments except that one thing about me being nervous about "plugins". Each modification is different and db format does not actually matter. I am far beyond that point in my php knowledge.
The 2 facts make me nervous: files bulkup and possibly faulty architecture. And if that doesn't make you nervous, then I think it's ok, because you might be more experienced than me.
beholder - file bulkup ... hmmm did you saw how it works in old version? script open file and fwrite( ); data in for or foreach. For example you have 2000 products then to save file data script must do this:
and its works ... then why should it have more problems when you have all data storaged in variable (as it is now in old version too for example $aProducts in class Products). Then if when scripts get data and unserialize from 'products.txt' then when it will save this data memory will not overloaded. In new way scripts saves data like this:
w poprawce do wersji 3.2 - 4 punkt XHTML validation funkcja zmiany wielkości tekstu po zamianie tej funkcji jest ok ale zauwazyłem mały uszczerbek, nie działa zmniejszanie i powiększanie tekstu na stronie z podstronami, na tychże podstronach, pewnie o tym wiecie, ale coś za coś
I poprawcie dla przyszłych wersji Q.Cart (Q.Cms nie dotyczy bo jest tylko 1 db z _xxxx_files) funkcję deleteFilesFromDirs(). Teraźniejsza ma brzydką przywarę kasowania plików z serwera, jeśli są przypisane w innych miejscach. Założenie: 1 plik dodany do 1 strony i do 1 produktu. Wyłączona opcja: kopiuj pliki na serwerze. I co się dzieje: Kasujemy ze strony. Pętla wrzuca bDelete=true i szuka, czy jest jeszcze taki plik w db1 (pages_files) z innym numerem. Nie ma, idzie do db2 (products_files). Jest -> bDelete= false, nie kasujemy. Kasujemy z produktu. Pętla wrzuca bDelete=true i też szuka najpierw db1. Jest -> bDelete=false i szuka teraz w db2, przy czym zaczyna od postawienia bDelete=true. Niestety w db2 nie znajduje duplikatu, więc na false nie przerzuci, czyli kasuje, bo bDelete=true. I na stronie, gdzie był obrazek, zieje pustka. Zmieniłem to tak, że zamiast bawić się w przełączanie bDelete, po prostu przy znalezieniu gdziekolwiek duplikatu robię "wypad z baru", czyli return null. Dodatkowo dołożyłem sprawdzanie w plikach "drugojęzycznych". Cały przeze mnie zmieniony kod do obejrzenia tu: http://forum.quicktoolsfactory.com/index.php?p=topicsMore&iTopic=10
Spróbowałem jeszcze raz. 1. Download virgin QC42 Free; 2. Konfiguracja -> Kopiuj pliki wybrane z serwera: NIE; 3. Dodaj nową stronę i jakiś obrazek do niej z lokalnego komputera; 4. Dodaj nowy produkt do jakiejś strony i dodaj do niego obrazek z serwera (ten nowo dodany do strony z punktu 3.); 5. Skasuj obrazek z panelu edycji strony -> obrazek zostaje na serwerze; 6. Przywróć stronie obrazek (z serwera); 7. Przejdź na nowododany produkt. Skasuj obrazek -> obrazek znika z serwera, mimo, że jest przypisany do nowododanej strony.
dzieki za zgloszenie bledu. Rozwiazalem to inaczej niz Ty bo Twoj przyklad ma 3 wady: - podatnosc na przepelnienie pamieci bo wrzucasz wszystko do funkcji file() co przy duzej ilosci produktow i plikow dociaza pamiec znacznie. - mala wydajnosc bo przy usuwaniu strony z 20 plikami funkcja usuwajaca pliki z serwera wykonuje sie 20 razy. W takim razie na te 20 razy w przypadku QC i sklepu majacego 3 jezyki skrypt bedzie "mielil" pliki w bazach danych w skrajnym przypadku az 80 razy + przegladanie indeksow dla aktualnego jezyka!!! W moim przypadku 6 razy ( 3 x po 2 pliki (products_files i pages_files) ) - jesli jakims cudem ktos doda opis pliku taki sam jak nazwa pliku to skrypt nie usunie pliku mimo, ze powinien - watpie, ze ktos bedzie mial opisy plikow z ich nazwami w innych plikach ale wolalem sie zabezpieczyc.
Poprawka znajduje sie tutaj: http://opensolution.org/download/Quick.Cms/bugFixes.html
Z tego samego powodu ("... jakimś cudem ...") nie dałem explode i nie szukałem w "zagranicznych" w konkretnym polu, tylko w całej linii. Choć może wartoby dodać, bo w zasadzie już widziałem "a.jpg", "b.jpg" itd. A jeśli chodzi o skrajne przypadki, to wysadzam funkcję w kosmos już po pierwszym duplikacie - czyli być może już w drugiej/trzeciej linijce db. Twoj pętla ciągnie do końca (po co?). Co do przepełnienia pamięci (file()): sam w górnym poście pisałeś, że performance w adminie nie jest taki ważny ;-)
boboo - zle zrozumiales zachowanie kodu, ktory napisalem. Twoj kod szybciej zadziala jesli plikow do usuniecia jest pare np. 1-2. A co jesli plikow jest do usuniecia 15-20 z np. listy plikow w administracji i ktos ma 3 jezyki i wystepuja duble tych plikow w np. stronach/produktach? Ale to moim zdaniem glupota bo czy skrypt sie wykona 1 czy 2 sekundy w tak rzadko wykonywanych akcjach to juz nie ma wiekszego znaczenia.
Natomiast problem wiekszy to zapelnienie pamieci i performance o ktorym wspomniales do przepelnienia pamieci w tym przypadku ma sie nijak. Zapelnisz pamiec i skrypt sie wysypie, mozliwe, ze i baza danych sie wyzeruje w skrajnym przypadku. Wazne to, ze za kazdym razem pobierasz dane plikow do zmiennej $aFile a indeksy z produktami, plikami i stronami z zapelniaja juz znacznie pamiec. Wiec wyobraz sobie, ze indeksy zajmuja juz 12 MB a Ty pobierasz do zmiennej $aFile za pomoca funkcji file() kolejne 5-6 MB ... i bum memory overloaded. Tu oczywiscie mowa o sytuacji gdy ktos ma np. 1000 produktow, 100 stron, 4000 plikow i maly przydzial pamieci na serwerze.
rozwiązanie z dodawaniem zdjęć jest zarąbiste, mniej trzeba się naklikać i nic nie znika i nie przeskakuje w dół, dużo jest kombinowania żeby w adminie w opcji strony stworzyć w wersji 3.2 dokładnie taką samą zakładkę "Dodaj pliki" i "Pliki" co trzeba przekopiować z wersji 4 żeby miec takie coś w 3.2 Ewentualnie ile takie cos kosztuje ? ktoś sie tego podejmie? czekam na ceny.
Wrócę jeszcze do kwestii nowego lightboxa. Znalazłem skrypt który jeszcze mniej zajmuje http://code.google.com/p/mini-lightbox/ no ijest jasno napisane na jakiej udostępniono go licencji czyli MIT. A co obecnego sktyptu lightboxa w w tej nowej wersji to przecież u nich na stronie pisze że skrypty są udostępnione an licencji CC BY więc trzeba będzie napisać gdzieś info że cms korzysta z tego skryptu.
DarkSilver - tak oczywiscie bedzie. Informacje o licencji beda wpisane w pliku read-me.txt. Co do mlbox'a to zaleta jego jest taka, ze autor dosc szybko reaguje i dokonuje poprawki. Patrzac sie po dacie ostatniej aktualizacji tego mini-lightbox to moze byc roznie ...
Kolejna sprawa to ten lightbox uzywa rel="", ktory wkrotce wyjdzie z uzycia. mlbox uzywa juz class=""
No i problem w tym, ze ten mini-lightbox nie ma przewijania poprzedni - nastepny ... chyba, ze zle go obsluguje :)