motyc
commented
5 years ago Pokud v tom nenajdete nějaký háček, vyřešil jsem celkem elegantně náš problém s filtrací podle data - stačí v rámci DT brát vždy to nejmladší datum z logu stavů.
Ve specifikaci níže jsme ponechal jen ta pole, která se mají brát v úvahu. Tam, kde je pole jen jedno, tak je to jasné. V ostatních případech se vezme vždy jen nejvyšší datum (myšleno nejmladší) a tím pádem bude datum záznamu skutečně odrážet na denní bázi záznamy, které se změnily, a to jakýmkoli způsobem. Snad taková agregace nebude problém, ale stejně bychom něco podobného museli u akcí řešit tak jako tak...
Jediný problém je s DT let, což je položka u které datum vztažitelné k evidenci chybí. Použijeme tedy prozatím datum letu.
pbartosova
Přemýšlel jsem nad nutnými filtracemi nad daty poskytovanými pro jakékoli API a vyšla mi tato tři nepřekročitelná kritéria, která nějak musíme zohlednit: 1) filtrace na základě procesního stavu 2) filtrace na základě přístupnosti záznamu 3) zobrazení/nezobrazení osobních údajů (částečně souvisí s oběma předchozími)
Jako "nice to have" bych přidal ještě datum archivace, případně i jiných změn stavů, ale to už pro začátek není tak podstatné.
Prosím zamyslete se, jak to řešit. Jako nouzová varianta mi přijde data filtrovat již při exportu do XML. Vznikaly by tak dílčí bloky/soubory pro jednotlivé skupiny dat, takže API by pak již jen bralo ty správné, které mají být danému uživateli při daném dotazu k dispozici.
Poptávka pro stahování dat, které se změnily po nějakém datu.