Nette caching configurace z db

theacastus

Zdravím,

řeším jestli když potřebuji v administraci, ale i jinde na stránce mít různý počet článků na stránce – například, čekají mě i další věci ale tohle je příklad který mě momentálně pálí nejvíc

Mám jednoduchou tabulkou settings jejíž schéma je velmi jednoduché:
id | key | value | displayname

id je pro snadnou reprezentaci a práci v databázi, key bych použil v cachi a displayname je pro tabulku, protože nechci někde hardcodit názvy a když něco přidám tak to dopisovat, chci aby se s tím dalo pracovat jednoduše – přidám záznam celý, key, value a co se zobrazí v administraci.

Uvažuji nad sloupečkem ve kterém bych měl informaci o typu, int/bool/string… atp. popř. mít sloupec pro hodnoty kterých to může nabývat, abych například v selectu, měl rovnou hodnoty které bych tahal přes foreach a bylo to oněco víc dynamické, na druhou stranu je to asi zbytečné, když do nastavení člověk neleze denně.

Uvažuji zda mít v BasePresenteru – startUp() – kde bych setoval hodnoty do constant, díky kterým by to bylo kdekoliv dostupné, zas je zbytečné mít query navíc pro každý request v administraci – proto bych šel cestou cache, ale vyplatí se to ?

Nebo mám používat query jen tam (v presenteru většinou) kde ho přímo potřebuji?

Pokud bych šel cestou cachi, kdy mám cache invalidovat? Myslím že by stačilo jen při změně, jak do cache efektivně uložit data… nebo po údržbě mít call v cli, který by řekl aplikaci ať vyrenderuje templaty, cache atd… ?

A je dobře že takhle myslím na UX, když jsem relativně začínající, ale v nette se už nějak orientuji – není to že googlim úplně každou věc :D

Díky všem :-)

vladimir.biro

Ahoj. Zrejme ti v tom velmi nepomozem, len by som chcel povedat, ze volat pri kazdom requeste nieco tak dolezite ako su nejake nastavenia je asi ok. Tam byva vacsinou problem v tom, ked ma niekto dva krat (a viac) to iste query, alebo vola data z databazi v nejakej foreach iteracii a tak podobne.

Ja som kedysi robil dokonca to, ze som si z databazi zavolal zoznam produktov, dal som si ich vypisat v nejakom cykle a v kazdej iteracii som z DB tahal konkretne udaje o produkte. :D :D

Ale tvoje volanie nastaveni by malo byt OK. Aspon podla mna teda.

A ci to volat v BasePresenteri, alebo v konkretnych presenteroch, to je skor vecou programatora, ako si chce ulahcit zivot :) .. pokial potrebujes tie nastavenia len obcas, tak je asi lepsie tahat si to v konkretnom presenteri. No pokial tie data potrebujes v 80% vsetkych presenteroch, tak je asi luxusnejsie mat to v Base :)

BTW som pripraveny na silnu oponenturu, pretoze toto vsetko su len moje subjektivne nazory :)

Editoval vladimir.biro (9. 11. 2017 11:53)

theacastus

V administraci je cca půl presenterů které zobrazují seznamy a jsou stránkované, chci mít možnost aby si zvolili sami (když potřebují) kolik jich chtějí na stránku (výsledků z db) a zároveň chci nějak unifikovat to číslo které je default, proto jsem chtěl db config.

Rozhodl jsem se v Admin modulu dát do base-presenteru const ITEMS_PER_PAGE s tím že když mám list presenter tak používám toto:

namespace XXX;

use xxx;

class PostListPresenter extends BasePresenter
{
	...
	public function renderDefault(int $page = 1, int $itemsPerPage = parent::ITEMS_PER_PAGE)
	{
		...
	}
	...
}

V BasePresenteru budu načítat hodnotu (asi z DB teda? +1 query něco na způsob SELECT value FROM settings WHERE key = 'ADMIN_ITEMS_PER_PAGE' ?

A ve Front modulu bych to použil jen u postů kde bych si to volal přímo v presenteru…

Což mi přijde celkem OK podel toho co psal @vladimir.biro

I když bych asi mohl zkusit napsat něco pro cache a pak to zkusit testovat v produkci jak je co rychlé :D

EDIT:
Tak jsem se rozhodl si to jednotlivě volat v presenterech kde to potřebuju, necelých 50% presenterů kde to potřebuji, to nechci mít v BasePresenteru

Editoval theacastus (9. 11. 2017 16:38)