Názory k článku Nekonečný list pomocí RecyclerView a Microstream (Android)

Díky. Jen prosím o případnou opravu výpisů generik, místní editor pomíchá špičaté závorky.

Děkuji za upozornění. Společně s redakcí jsme problém opravili.

Prosim pekne, nepouzivejte v ceskem clanku pro 'seznam' vyraz 'list'. Ja sice chapu, proc to tak pisete, ale v cestine, kde slovo 'list' normalne existuje a ma zcela jiny vyznam, to pusobi celkem podivne.

Dobrý den,
děkuji za upozornění. Máte pravdu, dám si na to příště pozor.

mne naopak prijde lepsi pouzit skutecne anglicky list...

A v čem? Když napíšu "list", není poznat, jestli myslím anglický nebo český, je to dvojzačné. Takhle jsem se jednou nachytal v diskusi s kolegou, kdy jsem myslel "list" v českém významu, on ho chápal v anglickém a pořád mě tvrdil, že je to blbost a až po nějaké době jsme zjistil, kde je problém a proč si nerozumíme...

Z praxe se mi mockrat potvrdilo ze mit zdrojovy kod v jakemkoli jinem jazyce nez v anglictine je jak loveni mamutu bumerangama. Divne, neefektivni a jednou se to vrati a da vam to poradnou facku :)

Ale vazne: Cely zdrojak je v anglictine, odkazuje se na `list view`, takze mi prijde spravne pouzivat anglickou terminologii.

S tím bych i souhlasil, tedy s tím, že občas může být problém s terminologií business domény, která může být obtížně převoditelná do angličtiny, případně převoditelná je, ale zákazník to nepoužívá atp.

Nicméně tady se bavíme o textu článku (viz první příspěvek vlákna).

IMHO není nic špatného na tom mít ve zdrojáku "class", "String" a "List" a mluvít přitom o třídě, řetězci a seznamu (pokud jde o v češtině běžně zavedené termíny).

Nebylo by řešení, použít třeba kurzívu na anglické termíny? Problém může nastat, když se to skloňuje např. listu, ale i to by šlo.

„Nekonečný list pomocí...“
A jedná se o list rostliny, papíru, nebo ještě nějaký jiný?

Mě zaujal ten Microstream. Vypadá, že to je nová věc, ale po chvíli pátrání se dá zjistit, že to je nějaký přejmenovaný JetStream? Proč to výrobce neuvádí? Dá se tomu věřit, myslí to s tím výrobce vážně? Zdá se že to je closed source. Máte s tím někdo širší zkušenosti?

Těch pokusů tu bylo víc, db4o, Zoodb, OhmDB, Nitrite... Nejpokročileji vypadala db4o ale výrobce ji zaříznul a existuje jen nespočet forků, které nikdo neudržuje. Ostatní vypadají jako minoritní projekty.

Dobrý den,
na to vám můžu odpovědět jako autor zcela přesně. JetStream byl původní produkt firmy XDEV, která vyvíjí RAD nástroje pro GUI, Rapidclipse a provádí zároveň zákaznický vývoj. Jelikož bylo vždy problémem dál vyvíjet tento produkt, protože zákaznické projekty měly vždy přednost, došlo k rozhodnutí, že se JetStream osamostatní, tak aby nedocházelo k tomu jevu dále a produkt mohl být dále vyvíjen. Při registraci jména JetStream bylo tenkrát objeveno, že již existuje pro Javu tool se stejným názvem, došlo k tedy k přejmenování firmy a nástroje na MicroStream.
Toto přejmenování bylo uděláno z právních důvodů, nic jiného za tím nebylo. S novým názvem MicroStream by se tato situace již neměla opakovat.
Už jenom kapitál, co byl investory vložen do vývoje této technologie zaručuje další vývoj.
https://spotfolio.com/2019/12/10/neues-zeitalter-der-datenspeicherung-startup-microstream-erhaelt-investitionskapital-in-millionenhoehe/

Děkuji za odpověď. Podle mě by projektu prospělo, kdyby toto bylo explicitně uvedeno i na stránkách. Ostatně - pokud je nástroj historicky prověřený, může to jeho reputaci pouze pozvednout.

Jinak samozřejmě nejde jen o zajištění vývoje, ale i udržení licence, podpory, dokumentace, obecně o udržení konzistentní „politiky“ okolo projektu.

Každopádně držím palce a na MicroStream kouknu, vypadá zajímavě a pokud bude nyní více prostředků pro jeho vývoj, je to jedině dobře.

Dobrý den, předal jsem tento podmět kolegům.
Pro další vývoj a udržitelnost projektu zde děláme vše, co je v našich silách.
Ještě jednou Vám děkuji za komentář. Aspoň jeden je k tématu a obsahu článku a ne k používání anglických výrazů v českém textu.

https://javapro.io/jetstreamdb-heisst-jetzt-microstream/

Dobrý den,
dostal jsem od kolegů info, že přejmenování proběhlo tenkrát i tiskem. Akorát jenom v německém jazyce, postaráme se, aby to bylo někde zmíněno i v angličtině.

Mam dotaz k Microstreamu. Zkusil jsem si ulozeni 1M entit do mapy a pri kazde dalsi transakci (ulozeni mapy v rootu) se zrejme uklada cela mapa, protoze pri vetsi velikosti kolekce se zapis zpomaluje. Takze u velikosti mapy x10_000 to jiz celkem trva a velikost uloziste pak neni umerne poctu entit v kolekci.

Pokud pridavam prvky po jednom (tedy ne v davce), mel bych pridani zakoncit transakci. A zde se mi jevi, ze pokud na pozadi dochazi k ukladani cele kolekce a ne pouze rozdilu od minule verze, pak to je nelinearne tim vetsi problem, cim vetsi je ta kolekce.

Mam dotaz: Jaka je doporucena cesta k ukladani velkych kolekci? Existuje nejaky dobry zpusob, jak v Microstream spravovat (zakladni: list, set, map) kolekce s velikosti x1M?

Napadlo me akorat vest odkazy ne z objektu kolekce na jeji polozky, ale v opacnem smeru a nasledne vyhodnocovat formou dotazu. Tim ale problem nezmizi.

Zkusil jsem si ulozit take com.google.com­mon.collect.Im­mutableMap a net.openhft.co­llect.map.hash­.HashIntObjMap, ale s tim mela DB problem a bylo by mi nejspis treba proniknout hloubeji do custom value handleru.

Dobrý den,
na ukládání těchto rozsáhlých kolekcí není Microstream ta nejlepší volba. Každá technologie je silná v něčem a síla Microstream je v ukládání rozsáhlejších datových struktur v Javě. Objektového grafu. Ten uložit pomocí stávajících relačních databází není zcela triviální, kdežte s Microstream ano.

S pomocí Lazy můžete vždy držet v paměti třeba aktuální část, se kterou momentálně pracujete, zbytek nechat na disku a načíst pouze v případě potřeby.

V androidu, kde na mobilním zařízení nepředpokládám ukládání milionů dat a ta databáze tam slouží více méně jako lokální persistentní cache, to bude fungovat dobře.

Ohledně google collections, ty jsou v backlogu, tu druhou kolekci vidím poprvé. Pro custom type handler existuje ukázkový projekt:
https://github.com/microstream-one/examples/blob/master/customTypeHandler/src/main/java/one/microstream/sampler/customtypehandler/CustomBufferedImageHandler.java
https://manual.docs.microstream.one/data-store/customizing/custom-type-handler a dokumentace, která má poněkud potenciál na vylepšení.

Nez jsem se zeptal, tak jsem si ty handlery zbezne prosel. Proto to povazuji za mozny zpusob, ktery ale neresi "rozkrajeni" vetsi kolekce na mensi celky, ktere by slo spravovat separatne.

V jednom drivejsim prispevku (MicroStream used as a search server) jste odpovidal, ze by se search dal implementovat pres Microstream. Odvozoval jsem od toho, ze jiz s velkymi kolekcemi je nejaka zkusenost. Napriklad, ze bude existovat vhodnejsi implementace pro transparentni pouziti, vhodnejsi pro uziti s Microstream.

> V androidu, kde na mobilním zařízení nepředpokládám ukládání milionů dat...
Tam to bude OK, ale hodila by se serverova technologie, kde jsou instance objektu prolinkovany do jednoho velkeho spojiteho grafu, ktery je omezeny pouze velikosti pameti.

> na ukládání těchto rozsáhlých kolekcí není Microstream ta nejlepší volba.
Skoda, ze je to uzavrena technologie. Myslim, ze by se to dalo resit.

Kazdopadne dekuji za odpoved a budu se tesit na dalsi clanek.

Teď Vám už lépe rozumím. Rozsekání řešitelné je už nyní, na to existuje přímo podpora.

Pokud si uděláte object, kde budete mít List<Lazy<List<T>>> tak můžete tu kolekci rozsekat na části a ty načítat podle potřeby z paměti. Můžete tam použít například Map<someKey, Lazy<List<T>>> a načíst si přímo tu část, kterou budete potřebovat a s tou pracovat. Pak nebudete omezen velikostí paměti a ty data si načtete podle potřeby a ty můžete následně ihned uvolnit.
Lazy můžete použít kdekoliv a s tím by se asi váš problém dal řešit.

Pochopil jsem to správně?

https://forum.microstream.one/?qa=18/whats-best-practice-if-storage-is-bigger-than-ram
Tady jsou ještě popsané nějaké způsoby práce s velkými daty.