Fulltext search about cityvizor HOT 16 OPEN

Bavil jsem se o tom s @martinwenisch a je spis pro Lucene.
Vyhody: in memory, v pripade typeahead vyhledavani pri psani do formulare to nebude bombardovat databazi

Refactoringy vyresim a pripravim to nad aktualnim masterem.

from cityvizor.

From @janvlasaty on March 1, 2018 18:5

Dodavatele popisy akce rozpočtové kapitoly

Copied from original issue: otevrena-data-mfcr/CityVizor#135

Ahoj, to v textu jsou popisy oblastni, ktere bude mozne vyhledavat fulltextem? Tzn. vyhledávání v:

• v dodavatelích
• v popisech akcí
• v rozpočtových kapitolách

Jsu to všechny možnosti? Napadá mě minimálně například v názvu faktury? Kdo definoval to výše uvedené?

from cityvizor.

Je řešeno v Trello board: https://trello.com/c/wQmdWQFb

from cityvizor.

Pro fultextove vyhledavani je potreba:

• Navrhnout API/Datovy model pro query endpoint + API test (napr postman collection/jmeter)

• Datova analyza a implementace backendu (v jak velkych datech se hleda ted, v jak velkych datech se bude hledat pri 700 zapojenych obci)
  Vyber technologie (inmemory Lucene, query v postgresql ...) a implementace backend API

• Upravit frontend (hlavicka pro vyhledavani + vysledky)

Figma design:
https://www.figma.com/proto/223Q7ZT1zFAhdVhiOZiw4r/Cityvizor---aplikace?node-id=2%3A2&viewport=1291%2C352%2C0.4990067183971405&scaling=min-zoom

from cityvizor.

Po domluve s @HormCodes se pridavam.

from cityvizor.

Co znamena rozpoctova kapitola?
Popr. mohl bys @SmallhillCZ popsat jake tabulky.sloupce to presne znamena?
Dokazu ze sample dat dostat sloupce ve kterych ma smysl hledat, ale nerad bych nejaky zapomnel.

from cityvizor.

Koukal jsem na ten full text search pull request (ktery jsem bohuzel vsema tema refactoringama nejspis zabil) a napadlo me, jestli to neudelat pres full text search podporu v Postgresu.

from cityvizor.

Proti postgres fulltext jsem argumentoval hlavne flexibilitou ve chvili, kdy nemame uplne detailni zadani z UX pohledu (presne nevime, k cemu se ten fulltext bude pouzivat).

• Puvodne pred hackday (a co jsme brali v uvahu pri te puvodni analyze) byl pozadavek na vyhledavani-behem-psani, na coz je inmemory lepsi.
• Data nejsou velka, index nepreroste rozumnou memory instanci na AWS (napriklad).

Postgres ma hodne pokrocile vyhledavani, ale:

• defaultne nepodporuje cestinu pri tokenizaci
• indexace tsvectoru je narocna, bezne se ukladaji spolecne s daty => je potreba upravit schema.
• jsem spis fanousek pouzivani nastroju na aplikacni urovni nez na databazi, pokud se ta DB pouziva jako hlavni databaze pro CRUD. (ciste bias, jde argumentovat i obracene :)

Kazdopadne, neberte to jako, ze do toho hazim vidle a klidne si udelejte vlastni analyzu.

from cityvizor.

Jo jo, ja jsem se do toho taky chtel pustit, ale zastavilo me prave to, ze nevim jak to bude pouzite.

from cityvizor.

@michalsvec, @Jubbaakk, @HormCodes můžeme doplnit nějaký update? Díky!

from cityvizor.

@HormCodes zkouším připomenout tuto issue. Nevíš prosím o updatu? Děkujeme moc!

from cityvizor.

Backend je funkcni od PR #96. Chybi frontend a pak pravdepodobne vyladeni samotneho searche podle vysledku nad realnymi daty.

from cityvizor.

prosím tech leads @sitina a @lukas-krecan, zda by nenastínili další kroky, např. zkusit aktivovat nějakého frontenďáka apod., díky @michalsvec a @Adel770-gl za kontrolu!

from cityvizor.

@michalsvec Michale, co myslim frontendem? Integraci vyhledavaciho pole do prehledu, giz napr: https://cityvizor.cz/praha1/prehled?

from cityvizor.

@evapavlik frontend navrhoval Vojtech Svec jako separatni stranku s vysledky vyhledavani.

from cityvizor.

@michalsvec Kdyz koukam do te Figmy nahore, tak me to prijde jen jako pridani jednoho vyhledavaciho pole do stavajiciho designu?

from cityvizor.