developer toolbox » harbour

džonim iz #24717

počistio fmk tako da radi update schema iz skeletona

https://github.com/knowhow/fmk/blob/master/database/misc/db_migrate.sql
https://github.com/knowhow/fmk/blob/master/database/views/views_migrate.sql
https://github.com/knowhow/fmk/blob/master/database/views/views_rnal_migrate.sql

ovo sada radi:

hernad@macan:~/github/harbour_playground/pgsql$ ./dbf2pg -h localhost -y 5433 -d quick38 -u admin -p admin -e fmk -f fmk/KIF  -t fin_kif -c

CREATE SEQUENCE  fmk.sem_ver_fin_suban START 1;

CREATE TABLE IF NOT EXISTS fmk.semaphores_fin_suban
(
  user_code varchar(20) NOT NULL PRIMARY KEY,
  algorithm character(15) NOT NULL DEFAULT 'full',
  version bigint NOT NULL, 
  last_trans_version bigint DEFAULT currval('fmk.sem_ver_fin_suban'),
  last_time timestamp DEFAULT CURRENT_TIMESTAMP,
  last_trans_user_code varchar(20)
);

SELECT setval('fmk.sem_ver_fin_suban', 1);

GRANT ALL ON TABLE fmk.semaphores_fin_suban TO xtrole;

setuj inicijalnu verziju lokalnog keša:

insert into fmk.semaphores_fin_suban(user_code, version)   values ('hernad', 0);

update-uj verziju:

update fmk.semaphores_fin_suban set version=0 where user_code='hernad';

select * FROM fmk.semaphores_fin_suban;

rezultat:

"hernad";"full           ";0;1;"2011-10-27 15:42:16.61563";"" 

svaka tabela znači ima svoju pridruženu "semaphores_ ..." tabelu

ovo ne radi unutar jednog u2.execute

CREATE SEQUENCE  fmk.sem_ver_fin_suban START 1;
SELECT setval('fmk.sem_ver_fin_suban', 1); <<<<<<<<<<<<<<<<<< kaže nije kreiran objekat fmk.sem_ver_suban 

CREATE TABLE IF NOT EXISTS fmk.semaphores_fin_suban
(
      user_code varchar(20) NOT NULL PRIMARY KEY,
      algorithm character(15) NOT NULL DEFAULT 'full',
      version bigint NOT NULL, 
      last_trans_version bigint DEFAULT currval('fmk.sem_ver_fin_suban'),
      last_trans_time timestamp DEFAULT CURRENT_TIMESTAMP,
      last_trans_user_code varchar(20)
);

CREATE INDEX on fmk.semaphores_fin_suban(user_code);
GRANT ALL ON TABLE fmk.semaphores_fin_suban TO xtrole;

a iz pgadmina radi ?!

ali sam mu dohak'o :)

prvo sam kreirao tabele i sekvence

a onda posebno setvalue

evo use case-a u kome prvo user koji se logirao update-uje semafor, nakon toga drugi, pa treći, pa četvrti user

hernad@macan:~/github/harbour_playground/semaphore_demo$ ./demo_1

Ulazni parametri:                                                                                                                                 

hernad settings
------ brisi ovo na drugom racunaru ----
setujem default engine ...DBFCDX        
table= konto                    
update_semaphore_version admin 49 <<<<<<<<<
table= konto                     
neki drugi user update 50   <<<<<<<<
table= konto             
neki treci user update 51  <<<<<<<<<<
table= konto             
neki cetvrti user update 52  <<<<<<<<<
get_semaphore_version admin 49  <<<<<<< semafor admina pokazuje njegovu verziju
aktuelna verzija na serveru 52 <<<<<<<<< zna se međutim da je aktuena verzija ova

kreiranje dbf-ova¶

https://github.com/bringout-fmk/ld/blob/harbour/tdb_ld.prg

https://github.com/bringout-fmk/fmk_common/blob/harbour/fmk_roba/db_integracija.prg

db funkcije https://github.com/bringout-fmk/fmk_lib/tree/harbour/fmk_db

prvi testovi su ... oouu ?¶

full update test

partn.dbf, partn.cdx mi smješta u $HOME/.fmk

u drugoj konzoli promjenio $HOME tako da mi pokretanje u dvije konzole sa različitim home simulira multiuser rad.

insert dbf/sql komanda traje na 10 000 zapisa poprilično nekih 20-30 sekundi.

ali ono što je fascinantno jeste da kada se vrši kupljenje podataka sa servera podaci se stavljaju u dbf <= sql baze ... to traje bukvalno tren na svim ovim slogovima ?!

znači da je ovaj nagluplji algoritam na jednosatvnom šifrarniku od 10 000 zapisa apsolutno OK. Već sada se brže otvara baza nego u većini situacija koje sam ja gledao kada imamo veće šifrarnike

naravno sve to će brže biti kada se podaci budu povlačili preko mreže ali ovaj rezultat me je skroz iznenadio. povlačenje podataka sa sql servera i punjenje dbf-a (prije toga uradim ZAP) jednostavno se odradi za tren za 10000 slogova.

jedva čekam da ovo probam sa udaljenim serverom i da to pokrenemo na 10-tak radnih stanica.

Ako brzina ne bude značajno pala, ovo je rješenje je onda samo takvo.

hernad@macan:~$ ls -l -h .fmk         10033  │ naz 10033                                                                                     
total 2552
-rw-r--r--  1 hernad  staff   206K Oct 28 00:08 partn.cdx
-rw-r--r--  1 hernad  staff   1.0M Oct 28 00:08 partn.dbf

i da 19100 slogova (ovo je veličina dbf-a) refreshiranje lokalnog keša sa algoritmom "full" ide ko munja

da li je tajna u tome što je partn sql tabela indeksirana ?! ma nije ... moraju se opet prebaciti svi slogovi

kreiranje fin_suban¶

kreiranje indeksa:

https://github.com/bringout-fmk/fin/blob/master/db/2g/db.prg#L589

novim commit-om se kreira i fin_suban, init verzija "date" algoritma

hernad@macan:~/github/harbour_playground/semaphore_demo$ ls -l -h ~/.fmk

total 1264
-rw-r--r--  1 hernad  staff    15K Oct 28 09:11 fin_suban.cdx
-rw-r--r--  1 hernad  staff   707B Oct 28 09:11 fin_suban.dbf
-rw-r--r--  1 hernad  staff   107K Oct 28 09:11 partn.cdx
-rw-r--r--  1 hernad  staff   502K Oct 28 09:11 partn.dbf

commit imamo hit !