F18

testirao upgrade...

na bazi 2010 dobijam ovo:

The following error was encountered while trying to import database/misc/fakt_atributi.sql into the database:

ERROR:  there is no unique constraint matching given keys for referenced table "fakt_fakt" 

CONTEXT:  SQL statement " 

    ALTER TABLE fmk.fakt_fakt_atributi
    ADD CONSTRAINT brdok FOREIGN KEY (idfirma, idtipdok, brdok, rbr) 
    REFERENCES fmk.fakt_fakt (idfirma, idtipdok, brdok, rbr);

    -- mora se koristiti xml entiteti lt, gt
    INSERT into fmk.fakt_fakt_atributi(idfirma, idtipdok, brdok, rbr, atribut, value) select idfirma, idtipdok, brdok, rbr, 'opis', opis as value from fmk.fakt_fakt where opis is not null and length(trim(opis))>0;
" 
PL/pgSQL function "execute" line 3 at EXECUTE statement

QPSQL: Unable to create query

hm... da, ovo je standardno problem ovog upgrade sistema....

Unutar transakcije je kreiranje tabele, i onda se radi ovaj ALTER ali on nije vidljiv praktično jer transakcija nije završena.

praktično bih trebao prvo napraviti

• upgrade sa 4.5.3 // kreira se fakt_atributi
• upgrade sa 4.6.0 // radi se alter itd...

... koliko mi se čini da postoji varijanta unuar package.xml da se navede prerequsite sekcija, ali nisam 100% siguran

tako da bi mogao reći prereq = 4.5.3 recimo

da, postoji...

primjer:

  <prerequisite type="Query" 
                  name="Ensure retail package is at 1.0.0beta or doesn't exist" >
      <query>
        SELECT COUNT(*) &lt;= 0
        FROM (SELECT *
              FROM pkghead
              WHERE ((pkghead_version NOT IN ('1.-1', '1.0.0beta'))
                AND  (pkghead_name='retail'))) AS dummy;
      </query>
      <message>
        This upgrade requires either that version "1.0.0beta" or
        "1.-1" of the package named "retail" is installed or that no
        version of this package exists (see bug 8183 for the odd
        version number and bug 8499 for the package name).
      </message>
    </prerequisite>

što znači treba ovakav query otprilike:

SELECT COUNT(*) >= 0
FROM ( SELECT *
       FROM pkghead
       WHERE (( pkghead_version >= '4.5.2' )
       AND ( pkghead_name = 'fmk' ))) AS dummy;

Unutar transakcije je kreiranje tabele, i onda se radi ovaj ALTER ali on nije vidljiv praktično jer transakcija nije završena.

hmm da ... a trebalo bi da svaki skok sa verzije na verziju bude posebna transakcija ...

ovo prerequiesite pomaže serviseru ali se opet mora raditi upgrade u više koraka ... pa dobro i to je nešto

a šta ako se ova izmjena napravi u postojećem:

SELECT u2.execute($$

    ...

$$)
WHERE (u2.knowhow_package_version('fmk') > 40502 and u2.knowhow_package_version('fmk') < 40600);

znači dodajem uslov:

u2.knowhow_package_version('fmk') > 40502

to bi preskočilo vjerovatno ovu komandu i setovalo verziju na 4.6.0 što ne želimo :(

međutim, izgleda da nije uopšte ovo u pitanju... nego u sezonskim podacima nemamo primarne ključeve na fakt_fakt tabeli

ovo sam napravio i to sada radi.... međutim opet sam dobio istu grešku

da, identična stvar je kao i kada ručno pozovem ovaj upit unutar pgadmin-a

ALTER TABLE fmk.fakt_fakt_atributi
     ADD CONSTRAINT brdok FOREIGN KEY (idfirma, idtipdok, brdok, rbr) 
     REFERENCES fmk.fakt_fakt (idfirma, idtipdok, brdok, rbr);

ERROR:  there is no unique constraint matching given keys for referenced table "fakt_fakt" 

uglavnom ovo je ispravna prereq struktura... koja bi se koristila

   <prerequisite type="Query" 
                  name="Verzija mora biti >= 4.5.2" >
        <query>
          SELECT COUNT(*) &lt;= 0
          FROM (SELECT *
                FROM pkghead
                WHERE (
                   ( pkghead_version &lt; '4.5.2' ) AND ( pkghead_name = 'fmk' )
                      )
               ) AS dummy;
        </query>
        <message>
          Ovaj update baze zahtjeva prethodnu verziju >= 4.5.2 !
        </message>
    </prerequisite>

naravno da mora postojati primarni da bi se setovao foreign key

može li se updater ispraviti ?¶

ovdje se desi begin transakcije https://github.com/knowhow/updater/blob/master/loader/loaderwindow.cpp#L943

mislim da postoji način da se unutar transakcije vide promjene koje si ti ranije napravio

ovo radi na podacima gdje fakt_fakt ima primarni ključ bez problema, evo sad sam testirao

radi starih podataka smo ukinuli ključeve

sezonski podaci krpaža¶

hmmm mislim da imam rješenje

trebamo označiti sezonske podatke parametrom

set_metric("foreign_key", "off") (ovo pišem napamet - pogledati kako glasi PLSQL funkcija i kako se poziva)

dodaćemo u u upgrade skriptu 4.5.9 verzija ovu funkciju:

CREATE OR REPLACE FUNCTION fmk.primary_keys_on_off()
RETURNS integer AS
$BODY$
DECLARE
  existsPK INTEGER;

BEGIN

IF exists(select 1 from pg_constraint where conname = 'navedi_ime_fakt_primarnog_kljuca_ovdje') THEN
  select set_metric('primary_keys', 1);
  existPK = 1;
ELSE
  select set_metric('primary_keys', 1)
  existPk= 0;
END IF;

return existPK;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION primary_keys_on_off() OWNER TO postgres;

pa ćemo je odmah iza toga i izvršiti u upgrade proceduri 4.5.9

select primary_key_on_off();

e sada imamo stanje koje možemo iskoristiti u sljedećem statementu:

SELECT u2.execute($$

    .... dio vezan za alter statement dodavanje foreign ključa

$$)
WHERE (fetch_metric('primary_keys') = 1 and u2.knowhow_package_version('fmk') < 40600);

ostatak statementa ide bez ovog uslova, tako da se primjeni i na sezonsko područje

baš sam ovo dobro smislio

ovo nije gotovo, ovo trebam ja pripremiti ?

ispravio greške unutar funkcije

CREATE OR REPLACE FUNCTION fmk.primary_keys_on_off()
RETURNS integer AS $BODY$
DECLARE existsPK INTEGER;

BEGIN

IF exists(select 1 from pg_constraint where conname = 'fakt_fakt_pkey') THEN
  select fmk.setmetric( 'primary_keys', '1' );
  existsPK = 1;
ELSE
  select fmk.setmetric( 'primary_keys', '0' );
  existsPK = 0;
END IF;

return existsPK;

END;

$BODY$ LANGUAGE 'plpgsql' VOLATILE;

ALTER FUNCTION fmk.primary_keys_on_off() OWNER TO postgres;

međutim, kada pozovem funkciju

select fmk.primary_keys_on_off()

dobijam:

ERROR:  query has no destination for result data
HINT:  If you want to discard the results of a SELECT, use PERFORM instead.
CONTEXT:  PL/pgSQL function "primary_keys_on_off" line 7 at SQL statement

ALTER FUNCTION fmk.primary_keys_on_off() OWNER TO postgres;

zar ower ne treba biti neko drugi (xtrole) ili ko je već kod drugih stvari ?

da, treba xtrole

CREATE OR REPLACE FUNCTION fmk.primary_keys_on_off()
RETURNS integer AS $BODY$
DECLARE existsPK INTEGER;

BEGIN

IF exists(select 1 from pg_constraint where conname = 'fakt_fakt_pkey') THEN
  perform fmk.setmetric( 'primary_keys', '1' );
  existsPK = 1;
ELSE
  perform fmk.setmetric( 'primary_keys', '0' );
  existsPK = 0;
END IF;

return existsPK;

END;

$BODY$ LANGUAGE 'plpgsql' VOLATILE;

ALTER FUNCTION fmk.primary_keys_on_off() OWNER TO xtrole;

ovo radi

da, testirao sam i ja

a gdje ćemo staviti ovu funkciju, unutar paketa u2 ili fmk ?

napravio verziju update paketa 4.5.9

http://code.google.com/p/knowhow-erp-f18/downloads/detail?name=f18_db_migrate_package_4.5.9.gz&can=2&q=

a sada pravim verziju 4.6.0

on će provjeravati da li ovaj paket postoji 4.5.9 prije njega...

http://code.google.com/p/knowhow-erp-f18/downloads/detail?name=f18_db_migrate_package_4.6.0.gz&can=2&q=

znači ovako...

U paketu 4.5.9 se ne može odmah i izvršiti funkcija primary_keys_on_off() zato što je u transakciji pa ne postoji još praktično...

Ono što sam napravio je da se unutar paketa 4.5.9 ona kreira...

U paketu 4.6.0 se kod provjere u where uslovu poziva

WHERE fmk.primary_keys_on_off() = 1 and ....

i to radi

hm, sad sam se sjetio da sam mogao vjerovatno i u prereq sekciju paketa 4.6.0 staviti ovu funkciju

   <prerequisite type="Query" 
                  name="Provjera primarnog ključa" >
        <query>
          SELECT COUNT(*) &gt;= 0
          FROM (SELECT fmk.primary_keys_on_off()
               ) AS dummy;
        </query>
        <message>
          Setujemo parametar primarnog ključa na bazi !
        </message>
    </prerequisite>

da, to je to... prilikom pokretanja ovog 4.6.0 paketa izvrši se ova funkcija i setuje parametar

commit

ono što je bitno naglasiti je, upgrade mora ići

1. 4.5.9

2. >= 4.6.0