sémakisimítás #174
Comments
|
Hát van rendrakni való. Sok mindent nem töröltem, mert nem mertem. (Ezért növeli a biztonságomat majd az unitest)
|
|
Ezt jó tudni, akkor itt csinálunk majd egy takarítást. |
… szentek, unnepnaptar táblák törlése borazslo#174
… szentek, unnepnaptar, updates táblák törlése borazslo#174
… szentek, unnepnaptar, updates táblák törlése borazslo#174
|
Nem nyitok a kérdésnek új issue-t. A gondnokság tábla (Holder) tartalmaz historikus adatot vagy a templom és a gondnok között mindig 1:1 kapcsolat van? |
|
Egy templomnak akárhány gondnoka lehet. Minden gondnokságnak van egy állapota. De egy templomhoz tartozó egy személynek egyszerre csak egy állapota lehet. Jelenleg igazából ezeket nem jól használjuk: az allowed és az asked az jó és fontos. A többi között nincs jó különbségtétel. Met pl. azt hiszem saját maga nem is tud még lemondani. Mindegy, majd egyszer: allowed': 'Enegedélyezett felelős', |
|
Mondd hogy mik a gondolataid ezzel kapcsolatban. Megcsinálom úgy. |
|
Állapotok:
Nem kezelt probléma, ami nem jelentős: ha a "hogy miért" mező mindegyiknél azonos, akkor ha valaki "revoked" kategóriába került mondjuk három éve, és aztán újra kéri és "asked" lesz, akkor a kérésénél beírt "hogy miért" mező felüliírja a régi "revoked" miértjét, és az "ez egy gazember enyje" estén probléma. De ilyen nagyon nagyon nagyon ritka lesz, és akkor úgyis letiltjuk a felhasználót a csudába. (Lehetne annyira egyszerűsíteni, hogy csak "asked" és "allowed" van, de jól jön, ha tudjuk, hogy miért lett eltávolítva vlaki. Ha pl. a egy templomnak több gondnoka volt és egyik rákérdez, hogy a másik miért... Info: a gondnokoknak nincs joguk más gondnokságát változtatni.) Hosszú távon: nem csak egy-egy templomnak lehet gondnoka, hanem egyházmegyéknek is (most a régi rendszerben egyházmegyei felelős még csak egy-egy személy, és később amikor a templom.plebania nem szöveges mező lesz, hanem klön adattábla belső relációkkal, akkor a plébániáknak is lehet egy vagy több gondnoka. De ezzel most ne törődjünk, működjön ami jelenleg van és akkor haladhatunk előre. Köszi a csodát |
|
osm táblának nem látom értelmét a templom mellett. a koordinátákat a templom is tárolja, más információ meg nincs benne. jól látom-e? |
|
Nem látod jól. Az osm tábla tökre fontos. A koordinátákon kívül egyes templomok akadálymentességére vonatkozó adatait és az OSM-ből szerezzük be (és oda küldjük vissza). A későbbiek során pedig az alapítás évét, a pontos címet, és akár még a nevét is az OSM-ből ill. azt szikronizálva. Az OSM adatstruktúránk olyan, hogy
Ezek az alapok, de aztán sok-sok tulajdonsága van minden egyes OSM izének. Ezek name: value formában vannak. Ilyen az OSM izé neve, wheelchair információk, és sok egyéb. Ezekez az A harmadik összetevő pedig a lookup_church_osm tábla. Ami összeköti, hogy melyik templom melyik osm izével egyezik meg. Mi a templom koordinátája?Hát ha van olyan OSM izé aminek van olyan osmtags-ja hogy "url:miserend" aminek az értéke, hogy "miserend.hu/templom/{saját_id}" akkor az OSM izének a lat.lng koordinátája. (Van még pár templom aminek nincs OSM izéje, de azok ötvenen vannak és halál rájuk, nem érdekel többé.) Az mondjuk helyes lenne, ha minden alkalommal amikor OSM lehúzzuk az adatokat (általános cron osm frissítés vagy a konkrét templom editre betöltése) akkor ezt a megszerzett koordinátát átvinné a templomok tábla koordináta pozíciójába. De szerintem ezt nem teszi meg. Most valami rettenet van, hogy amikor az eloquent betölti a church-öt akkor megpróbál létrejönni a church.location amiben van lat, lng, varos, orszag, egyebek. Ha van osm, akkor onnan veszi, ha nincs akkor templomok belső adatból. De közben létrejön a church.osm.tags is és benne a lat, lng, meg mindenféle. És aztán hol ezt hasnzálom, hol azt. Talán a legtöbb helyen a church.location-t már. A helyes megoldás az lenne, ha meglenne, hogy a templomokhoz tartozik jó sok oszlop benne egy egyszerű adat amit az OSM adatokból generálunk és így naaaagyon gyorsan elérhetőek. Effelé hajlik a boundaryAz hogy egy templom melyik egyházmegye területén van (és később az is, hogy melyik ország és város területén) az szintén OSM adatból is jöhet (ha meg nem akkor fallback-el templomok.egyhazmegye -re). Ezt úgy csináljuk, hogy az OSM adatbázisra küldünk egy API kérést az overpass api-val, hogy légyszi mond meg, hogy adot osm izé milyen területi osm izékbe tartozik vallási alapon. Pl. egyházmegye, meg espereskerület. És az overpass visszaad egy csomó OSM izét a hozzájuk tartozó osmtags-el (amiben ott a neve, meg a rangja meg ilyenek). Ezeket jól elmentjük az osms táblába és az osmtags táblába, hogy legyen meg. (Hmm, talán nem is lenne erre szükség?) Az boundaries táblába is elmentjük ezek közül a legfontosabb name:value párosokat szépen legyártva jó sok fontos oszlopot. A Ó, igazából itt is él az előző fejezet végi gondolat, hogy lehetne egy ilyen generálódó táblázat amiben egyszerűen ott van a lerövidítve a templom.egyhazmegye neve. (Ami lehetőleg osm-ből kiolvasva, de a "name" nevű kulcs nem biztos, hogy jó mert külföldon "name:hu" -kell, ha éppen van olyan... És ez még mindig nem minden :D miserend.hu/collection/{osm_type}:{osm_id}Publicba még nem ment ki, csak adminoknak azt hiszem. De kísérleteztem azzal, hogy legyen egy olyan egyszerű nézet, hogy mondjuk Szeged összes templom, vagy a második kerületé, vagy a Bakonyé. Erre azt találtam ki hogy adjunk meg az URL-be egy OSM izét (type:id párost). Akkor letöltjük annak a saját adatait (bele az osms táblába és az osmtags táblába) hogy pl, mi a neve meg ilyenek. ÉS letöltjük az overpass API-val hogy ennek az OSm izének a területén mely templomok vannak. Mehet bele a boundary-sba vagy az enclosed-ba. És akkor már csak egy szép felületre kell rakni és ripsz-ropsz készen vannak városi összefoglalók, amik nagyszerűek. És nem csak városokra, hanem bármilyen területi egységre amit ismer az OSM. És ez nagyon menő. EnnyiSzóval jól össze vannak itt a dolgok... És persze lehetne, hogy csak a "gyorsító" összekötő táblákat tartjuk meg és mindig frissen töltjük le az OSM adatokat és a válasz JSOn-ból csak a sázmunkra érdekeseket mentjük el. De valamiért így logikusabbnak és szebbnek hatott. Meg hát az biztos, hogy nem szabad minden alkalommal amikor egy felhasnzáló lekéri Szeged templomait, akkor nyolc opverpass API menetet nyomni. Legyen meg cache-ban. Vag y inkább akkor adattáblákban már. VAgyis... Szóval ilyesmi. |
|
tl;dr: Én támogatom, hogy írtsd a felesleget és egyszerűsíts. :D
|
|
Ha soha nem szeretnénk a templom alaprajzát megjeleníteni, akkor (jelenlegi ismereteim szerint) tulajdonképpen az OSM tábla és a kapcsolótáblája kuka. A metaadatokhoz (tags) bővítsük fel a church táblát plusz x mezővel és kerüljenek át oda. Accessibility pl mindenképpen, de meg kell nézzem milyen tag-ek vannak. További kérdés, hogy a templom idegen neveit nem akarjuk-e soha megjeleníteni. A symfonyban van eszköz a lokalizációra, és lehet csinálni fordítást, minimum az anoním módon elérhető felületekről, segítve ezzel a hazánkban élő / ide látogató embereket. |
|
(rákerestem a máriabesnyői templomra és egybe van rajzolva a templom a rendházzal. Szóval szép gondolat az alaprajz, de ha ilyen alapossággal rajzolták meg akkor inkább meh mint hasznos) |
|
Következő merényletem a SELECT c1.nev, c1.id, c2.nev, c2.id, st_distance_sphere(point(c1.lon, c1.lat), point(c2.lon, c2.lat)) distance_in_meter
FROM templomok c1
LEFT JOIN templomok c2 ON c1.id <> c2.id
WHERE c1.id = 408 AND c1.lat IS NOT NULL AND c1.lon IS NOT NULL AND c2.lat IS NOT NULL AND c2.lon IS NOT NULL
ORDER BY distance_in_meter
LIMIT 10;Kuka? |
|
Pontosan és ezért is van A cél, hogy minden misézőhelyhez meglegyen, hogy körülötte kik a legközeli misézőhelyek. A mapquest API-val szép lassan ki lehet számolni minden útvonal távolságot: mondjuk 1 km légvonal fölött autósat, az alatt gyalogosat. A cronban van egy distances számolás, amikor először leszűkítjük befoglaló dobozzal a lehetséges templomokat, aztán számolgatuk a mapquest API-val és ilyenek. Csakhogy jóóóó sok kell belőle, ami az elhibázások miatt ki-kimerítette az ingyenes keretet. (Bár ha jól működik fizetek én érte.) Illetve kissé bonyolult lett, hogy mikor frissítsünk milyen távolságokat. Szóval, hogy kell olyan metódus, hogy ha az OSM-ről új koordináta érkezik egy templomhoz akkor törlődjenek a távolságok ami az adott templomot érinti. De akkor újra kell számolni, hog ykik a közeli templomok, és nem csak annak a templomnak, hanem mindegyiknek ami potenciálisan érintett lehet. És mivel hibák esetén száz kilométert is jelenthet a változás, így a régi pont és az új pont körül is sok újraszámítás kell. Ezt nem sikreült optimalizálni. És a mapquest API ha kifutott a lehetőségből csak dobta a hibát mert még nem szereltem meg, hogy szép üzenet legyen és ne zavarjon. Viszont kiderült, hogy már a mysql nagyon gyorsan tud számolni st_distance_sphere()-t, ezért ideiglenesen (ha-ha) kiiktatásra került a distances és jelenleg nem használjuk. |
|
És ha átcuccolunk az openrouteservice.org-ra? |
Én úgy csinálnám, hogy a És aztán egy másik/új egyszerű church_id primary key-el rendelkező táblába tenném bele mind azt a plusz x extra mezőt, amit mindig az OSM-ből töltünk fel és töltünk vissza. Mert ez 15+ mező lesz pillanatok alatt.
Lehet, de akkor mégsem jó az előző terv. Mert mondjuk az OSM-ből lehúzzuk a templom nevét olykor 15 nyelven, akkor eleve létrehozunk 15 mezőt/oszlopot a church táblában? Van egy-két templom ahol van ennyi név. Vagy korlátozzunk magunkat, néhányra? |
Részemről lehet. De azért itt is figyelni kellhet. Ha minden és midnen között számolunk, akkor 5000 misézőhely x 5000 misézőhely. Ami tök sok. És sok idő is kiszámolni. Még jó hogy nem kell midnent. Szóval kell beléje logika, csak könnyebb ezzel. Átállhatunk. |
|
#172 issue kapott pár ötletet és közben megtaláltam, hogy van forráskód is az ors-hez. |
|
Valahol olvastam egy olyan gondolatot, hogy azért olyan amilyen a miserend sémája és logikája, hogy lássad a változásokat. Nem találom, hogy ezt hol írtad, de mi volt ezzel a cél? Kíváncsiság vagy egyfajta audit? |
|
#144 -ben írtam. Szituációk:
|
|
Rendben! Elgondolkodom, hogy ezt milyen meglévő eszközökkel lehetne megcsinálni. Auditra nagyon sok eszköz van, de itt tulajdonképpen adott esetben rollback-re, módosításra és jóváhagyásra is szükség van anélkül, hogy az alap miserend kirajzolása végtelenül bonyolulttá válna. |
|
Közben a Wiki-be bekerük az |
A #144-ben még írom hogy a a) mostani miserend adat struktúra igazából rossz. b) Konkrét miséket (pl. hogy holnap mikor lesz mise) amúgy is opcionális icals -ból jött adatokkal is kell keresni. Szóval bonyolultnak tűnik, de úgy "érzem", hogy évek szenvedése után egy soooookkal átláhatóbb, tisztább, és működőképesebb logika van mögötte. Én szeretem, de meggyőzhető lehetek. |
|
Egyrészt a mező szintű változásokat egy audit táblába külön kell rakni és az alapján követhető, hogy mikor mi változott. Másrészt az anoním javaslatot egy önálló miserendként kell elmenteni mint draft. Két miserendet össze kell tudni hasonlítani és amikor jóváhagyják a javaslatot akkor az kb rámentődik az élesre (amivel triggerel egy frissítést, csak azok a mezők változnak amik ténylegesen különböznek és így az audit táblába is azok kerülnek be amik változtak). Ezt követően a draft kukába kerül, mert érvényre jutott. És ez még nem a szerkezeti szintű kérdések, ez csak az üzleti logika. A jelenlegi rendszerban azt látom egyik problémának, hogy nem ismeri a unit of work patternt és emiatt minden mindig frissül (ha jól értettem a korábbi leírásodból). |
… szentek, unnepnaptar, updates táblák törlése borazslo#174
|
A |
|
Alapvetően simán lehet NULL a legtöbb helyén. Egy rossz gyakorlat ragadt be még sok-sok évvel ezelőttről. És jogos, hogy a created_at és registered_at világoknál a CURRENT_TIMESTAMP jó dolog. De szerintem el kell viselnünk ott is a NULL-t (amiko az "időszámításunk" előtt jött létre valami. ) Pusztítsuk mi feleslehes |
|
Elkezdtem dolgozni rajta. A dumpban NULL-ra cseréljem a |
|
Szerintem NULL-ra |
A repoban található dump pár helyen hibás.
egyébként a sémát lehetne tömöríteni is és akkor nem lenne ilyen nagy.
The text was updated successfully, but these errors were encountered: