Quick.Cms v4.0-rc1 - NON STABLE version - released!

treewood (OpenSolution)

Avatar: treewood

2012-01-25 22:50

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 :)

baron_jon

Avatar: baron_jon

2012-01-25 22:57

in my case that 20% is nothing, but database like this is very big disadvantage.

i can't understand why after manual changes in db all pages are missing. how does it work?

baron_jon

Avatar: baron_jon

2012-01-25 23:10

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 :)

beholder

Avatar: beholder

2012-01-26 05:13

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).

ok, this is it, I write too much

treewood (OpenSolution)

Avatar: treewood

2012-01-26 07:33

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

json
http://opensolution.org/_test/db-formats/db-json.txt

serialize
http://opensolution.org/_test/db-formats/db-serialize-full.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.

euphoria-art

Avatar: euphoria-art

2012-01-26 12:11

Panowie wyszedł już mlbox_v15, naprawdę są szybcy, Zaktualizujcie to też w ver4 to ja dokończe swoje testy ;)

www.ObrazyGaleria.pl - galeria obrazów

treewood (OpenSolution)

Avatar: treewood

2012-01-26 12:13

euphoria-art - tak jest!

beholder

Avatar: beholder

2012-01-26 15:13

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.

treewood (OpenSolution)

Avatar: treewood

2012-01-26 15:58

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:

$aFile file'products.txt' );
$rFile fopen'products.txt''w' );
$iCount count$aFile );
for( 
$i 0$i $iCount$i++ ){
 
fwrite$rFile' HERE DATA OF FILE' );
}
fclose$rFile );

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:

file_put_contents'products.txt'serialize$this->aProducts ) );


No for, no foreach and saving is much much faster then old one.

But ... life will show us how it works in practice :)

euphoria-art

Avatar: euphoria-art

2012-01-28 00:22

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ś

www.ObrazyGaleria.pl - galeria obrazów

euphoria-art

Avatar: euphoria-art

2012-01-28 01:46

sorry jest ok, pierwszy raz musiałem coś źle wgrać

www.ObrazyGaleria.pl - galeria obrazów

boboo

Avatar: boboo

2012-01-28 08:57

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

http://qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-01-28 09:47

boboo - z ciekawości przetestowałem kasowanie zdjęć na wersji Quick.Cart.Free w najnowszej wersji 4.2
Nie udało mi się odtworzyć Twojego problemu.


-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-01-28 10:27

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.

http://qc-plugins.kimla.de

treewood (OpenSolution)

Avatar: treewood

2012-01-28 13:28

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

boboo

Avatar: boboo

2012-01-28 14:58

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 ;-)

http://qc-plugins.kimla.de

treewood (OpenSolution)

Avatar: treewood

2012-01-28 16:07

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.

euphoria-art

Avatar: euphoria-art

2012-01-31 17:10

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.

DarkSilver

Avatar: DarkSilver

2012-01-31 17:47

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.

treewood (OpenSolution)

Avatar: treewood

2012-01-31 19:14

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 :)

Back to top
about us | contact