Database refetch failed; row does not exist

Taky mě to na jednom projektu dělá. Taky netuším proč. Ale nestojí mě za to to zjišťovat (náklady x užitek). Ale mám pocit, že to mělo něco společného s NDBT cachí. Jednou za čas to prostě jednomu člověku spadne, další requesty už chodí v pořádku. Začal jsem používat Doctrine :-) (Ne kvůli tomuhle problemu)

Taky mi to teď dělá, je to pro mě dost velkej problém (stává se mi to podstatně častěji než občas). Nic nestandardního nedělám, netuším, kde je problém.

Mě to dělá celkem pravidelně. Když na produkčním serveru vymažu cache, otevřu si dvě anonymní okna a v každém se přihlásím do své aplikace pod jiným uživatelem (každý má vidět jiná data) tak se ta chyba stane. Když nastane tak stačí refresh stránky a jede to dál…

Tracy jsem nahrál zde: „:http://faktury.cz/…te_tracy.htm“

Vůbec si s tím nevím rady.. a dělá to jen na produkčním serveru…

Ano mají vidět stejné sloupce, ale jiné řádky.
Primární klíč je ID záznamu. Select je pak pro každého uživatele s podmínkou cl_company_id = idCompany kde idCompany je ID firmy, ke které má uživatel povolen přístup.
Nic speciálního neselectuju, až v šabloně vybírám pole, které chci zobrazit.

CZechBoY napsal(a):

Ja si do modelu predam uzivatele a z nej vyberu treba roli nebo neco z identity.
Nevim jak moc je to good practise… Jestli je treba lepsi predavat roli/id firmy parametrem..

To ano takto to dělám (výběr id firmy z identity), ale problém nastává až potom při selectu nad tabulkou, kde použiju filtr právě na id firmy.

CZechBoY napsal(a):

A kdyby sis dal ty attachmenty nekde do vedlejsiho pole? Asociovany treba podle id ty nadrazeny tabulky..

Moc nerozumím jak to myslíš. Ale povedlo se mi trošku více problém izolovat. Totiž kromě filtru podle firmy tam mám ještě filtr na uživatel dané firmy, kterým je povolen přístup. Ti jsou zapsaní v další tabulce cl_partners_event_users.

Hlavní tabulka s daty je definována takto:
CREATE TABLE cl_partners_event (
id int(11) NOT NULL,
cl_partners_book_id int(11) DEFAULT NULL,
cl_company_id int(11) NOT NULL,
cl_users_id int(11) DEFAULT NULL,
work_label varchar(255) COLLATE utf32_czech_ci NOT NULL,
description longtext COLLATE utf32_czech_ci NOT NULL);

ALTER TABLE cl_partners_event
ADD PRIMARY KEY (id),
ADD KEY cl_company_id (cl_company_id),
ADD KEY cl_users_id (cl_users_id),
ADD KEY cl_partners_book_id (cl_partners_book_id);

ALTER TABLE cl_partners_event
MODIFY id int(11) NOT NULL AUTO_INCREMENT;

ALTER TABLE cl_partners_event
ADD CONSTRAINT cl_partners_event_ibfk_1 FOREIGN KEY (cl_company_id) REFERENCES cl_company (id),
ADD CONSTRAINT cl_partners_event_ibfk_2 FOREIGN KEY (cl_users_id) REFERENCES cl_users (id),
ADD CONSTRAINT cl_partners_event_ibfk_3 FOREIGN KEY (cl_partners_book_id) REFERENCES cl_partners_book (id);

Tabulka s oprávněními pro jednotlivé uživatele je zde:
CREATE TABLE IF NOT EXISTS cl_partners_event_users (
id int(11) NOT NULL AUTO_INCREMENT,
cl_partners_event_id int(11) NOT NULL,
cl_users_id int(11) NOT NULL,
cl_company_id int(11) NOT NULL,
PRIMARY KEY (id),
KEY cl_partners_event_id (cl_partners_event_id),
KEY cl_users_id (cl_users_id),
KEY cl_company_id (cl_company_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci AUTO_INCREMENT=87 ;

Samotný dotaz v modelu se pak skládá takto:

<?php
$this->tableName = 'cl_partners_event';
$this->userAccesTableName = 'cl_partners_event_users';
$company_id = 1 //id firmy z identity uzivatele;
$user_id = 2 //id uzivatele z identity;
return $this->database->table($this->tableName)->where($this->tableName.'.cl_company_id = ? AND ('.$this->tableName.'.cl_users_id = ?'.' OR :'.$this->userAccesTableName.'.cl_users_id = ?)',$company_id,$user_id,$user_id);
?>

Dotaz má fungovat tak, že vybere všechny záznamy, které patří dané firmě a uživateli, nebo patří dané firmě a uživatel je definován v přístupové tabulce cl_partners_event_users.

Tak jak to mám to funguje jak potřebuju, kromě těch pádů po vymazání cache…

Unlink napsal(a):

No, tá výnimka sa vyhadzuje v prípade, keď je nutný refetch dát (kvôli chýbajúcemu stĺpcu) a po znovunačítaní sa nepodarí načítať všetky pôvodné riadky.
https://github.com/…4cc47133f151

To je dôvod, prečo sa to nedá nasimulovať pri vývoji, kde nieje moc reálne, aby ti daný riadok zmizol. Takže podľa môjho názoru je výnimka legitímna, lebo sa nič s tým spraviť nedá. Každopádne, k tejto situácii by dochádzať nemalo, jedine ako som spomínal, že jeden používateľ vidí iné stĺpce ako druhý, vtedy to nastať môže.

Teď nevím jestli myslíš sloupce nebo řádky :-)
Pokud jde o řádky tak způsob jak je získávám jsem popsal výše. A je pravda, že v jiných částech programu, kde nepoužívám způsob přidělení záznamů uživatelům pomocí další tabulky se ta chyba zatím nevyskytla.

Pokud by šlo o sloupce tak tam mám ještě udělanou takovou věc, že si každý uživatel může nastavit jaké sloupce chce vidět… ale chyba o kterou jde říká, že "nemůže najít řádek ":http://faktury.cz/…te_tracy.htm

Unlink napsal(a):

No, a toto bude jadro toho problému, pokiaľ sa to deje len v po vymazaní cache a potom už nie, tak je je kvôli tomu, že medzi tým ako si prvý krát načítal záznamy a potom ako sa načítali po druhý krát nejaký záznam zmizol.

Aha, to co píšeš se může stát. Po vymazání cache první uživatel zobrazí stránku se záznamy s ID řekněme 1,2,3,4,5,6 a se sloupci A,B,C,D. Stránka se mu otevře v pořádku. Pak druhý uživatel otevře stránku, ale vidí jen záznamy 2,3,4,5 (protože k jiným nemá práva) a sloupce B,C,D (protože si to takto nastavil).
Takže v takovémto případě nette chce udělat refresh dat, protože je ještě nemá v cache. Je to tak? A chce dělat refresh pro záznam s ID 1 i když je tento záznam podmínkou vyloučen? Dá se říct proč to tak je?

Jinak zkusím tu úpravu co jsi psal a dám vědět.

Nie, najskôr sa prihlási prvý používateľ, nette, keďže nemá cache tak načíta všetky stĺpce tabuľky, ale používateľ si zobrazí len A,B,C čo si nette zapamätá. Príde druhý používateľ, nette si zapamätalo že minule sa použili stĺpce A,B,C tak načíta z databázy len nie. No druhý používateľ požaduje povedzme A,B,D. Stĺpec D nieje k dispozícii tak nette spraví to, že zoberie si IDčka všetkých záznamov ktoré načítalo a pokúsi sa načítať všetky stĺpce pre dané IDčka (SELECT * FROM table WHERE id IN(...)) no a teraz sa môže stať, že medzi tým ako prvý krát načítalo záznamy, a teraz keď ich číta druhý krát, tak nejaký záznam zmizol čo sa na zaťaženom serveri stať môže.

TomasHalasz napsal(a):

A ještě jsem se chtěl zeptat, když to funguje tak, že nette nemá sloupec D k dispozici tak bere všechny ID, které načetlo předtím a podle nich hledá záznamy. Proč v tu chvíli nepracuje podle aktuálně požadovaného ID?

Je to pre to, aby „obnovilo“ celú selection a nepokladalo dotazy pre každý riadok zvlášť.
A načítanie len konkrétneho riadku by nepomohlo, pretože táto výnimka nastáva práve vtedy, keď sa nepodarilo nájsť aktuálny riadok (inak to vypisuje undefined offset).

Skús mi napísať na email, a môžme to nejako zdebugovať, pretože ak to vieš nasimulovať tak to je super, lebo táto chyba zvyčajne nastáva náhodne, za situácii aké som popisoval o pár postov vyššie, takže u teba bude problém zrejme inde.

Môžeš vyskúšať tento fix?
https://github.com/…ase/pull/137
Ak to robilo náhodne tak by to mohlo pomôcť

Editoval Unlink (2. 6. 2016 17:02)

Pořád se mi tahle chyba občas náhodně vyskytuje. Last muted error je „Warning: fopen(xxx/app/../temp/cache/_Nette.Database.xxx): failed to open stream: No such file or directory“.

edit: Dostávám „Database refetch failed; row with signature ‚xxx‘ does not exist“, je to trochu jiná chyba.

Editoval filsedla (18. 5. 2017 10:21)

Super! Taky se mi jednou už povedlo najít konzistentní proceduru, jak to přivodit obsahující načtení stránky 2, 3, 7, 8 seznamu objednávek na produkčním serveru a udělání 10 dřepů. Pak jsem na to zapomněl. Tohle je lepší.

Myslím, že jsem to taky zkoušel xdebugovat, ale vůbec jsem tomu nerozuměl.

Chyba se stále objevuje a bude to tak, jak píše oldrich.valek.

1. Vymažu cache
2. otevřu stránku s komentáři (foreach), kde žádný nemá přílohu (funguje)
3. otevřu jinou stránku s komentáři, kde je příloha ⇒ bum „Database refetch failed; row with signature ‚44‘ does not exist!“

Stane se to vždy, když provedu tento postup. Po krátkém debugování jsem přišel na to, že je problém v tomto (snad to popíšu pochopitelně :-)):

1. vykresluje se první komentář/příloha, a ActiveRow::get zavolá ActiveRow::accessColumn
2. ActiveRow::accessColumn zavolá Selection::accessColumn
3. Selection::accessColumn zavolá postupně emptyResultSet (kde vyprázdní $this->rows) a execute (provede SQL a vytáhne nová data z DB do $this->rows)
4. nyní se začne vykreslovat další komentář/příloha, znovu se postupně zavolá ActiveRow::get → ActiveRow::accessColumn → Selection::accessColumn
5. Selection::accessColumn zavolá emptyResultSet , které vyprázdní $this->rows
6. Selection::accessColumn zavolá execute, které ale nic nedělá (viz podmínka !isset($this->refCacheCurrent[‚data‘], která nyní není „false“, protože byla nastavena u předchozího komentáře, v GroupedSelection::execute)
7. podmínka v ActiveRow: „if (!isset($this->table[$this->getSignature()]))“ způsobí chybu, protože $this->rows (ke kterému se přistupuje přes $this->table) je prázdné (viz bod 5)

My jsme se jej už téměř zbavili. Nemám tady kompletní soupis jako kolsi, ale stávalo se nám to hlavně v cronech.

Příklad – odesílání emailů

• 99% běhu cronu není co posílat, žádné emaily neexistuji, ($items jsou prázdný)
• pak se přidá email k odeslání, takže se vstoupí do foreach, kdy ale email není ještě autorizovaný, takže na první podmínce ->authorized je vráceno false a tím běh končí.
• jenomže v tu chvíli si database uložila do cache, že se přistupuje jen k sloupečku authorized.
• pak uživatel schválí odeslání emailu, a v dalším běhu cronu si již nette pamatuje, že si má tahat jen authorized
• na jakámkoliv dalším vytažení jiných dat, než je authorized to padne
• dočasným řešením bylo přidat select(‚*‘) (nebo samozřejmě vypsat sloupečky co budou potřeba) do všech metod, který tohle způsobovaly
• s tímhle to teď funguje bez problému, ale zbytečně se toho tahá moc

Tyjo, tri roky a tahle chyba se porad jeste objevuje…

Mne táto chyba začala vyskakovať

Database refetch failed; row with signature ‚1576‘ does not exist!

keď doťahuje $product->manufacturer->name

 <SHOP>
67:    <?php
68:            $iterations = 0;
69:            foreach ($products as $product) {
70:    ?>
71:            <SHOPITEM>
72:                <ITEM_ID><?php echo LR\Filters::escapeHtmlText($product->ean) /* line 8 */ ?></ITEM_ID>
73:                <PRODUCTNAME><?php echo LR\Filters::escapeHtmlText($product->manufacturer->name) /* line 10 */ ?> - Puzzle <?php
74:                echo LR\Filters::escapeHtmlText($product->name_cz) /* line 10 */ ?></PRODUCTNAME>
75:                <PRODUCT><?php echo LR\Filters::escapeHtmlText($product->manufacturer->name) /* line 11 */ ?> - Puzzle <?php
76:                echo LR\Filters::escapeHtmlText($product->name_cz) /* line 11 */ ?></PRODUCT>
77:                <DESCRIPTION>

ako to opraviť?

Editoval MKI-Miro (28. 10. 2020 23:31)

nette/database v3.0.5 💾 Nette Database: layer with a familiar PDO-like API but …

stejný problém, začal se teď objevovat na všech projektech

Me to ted nastalo na 3.0.6