WIP finishing Feature/ra #9
Conversation
…vs-edesks Data upvs edesks
update gems + Ruby to 2.4.1
Do not parse "effectiveDate" for MunicipalityChange, it is not part of the schema
|
|
||
| change: nil, | ||
| district_object: Ra::District.find(4764), | ||
| municipality: Ra::Municipality.find(92), |
There was a problem hiding this comment.
_object suffix som daval len k modelom naviazanym cez object_id.
Dalsou moznostou by bolo tie object_id asociacie spravit cez nieco ako objekt_id a objekt. Tym padom by sme to mali priblizne konzistentne a bez kolizii s Rails/Ruby keywordami.
There was a problem hiding this comment.
Aha, uz chapem terajsi change_id je vlastne objectId z xmlka? rozmyslam ci tam nedame nieco ako object_identifier kedze to nie je cudzi kluc nikam, je to nejake ich id. Tym by sa vyriesila nasty kolizia s Ruby object_id
There was a problem hiding this comment.
Praveze objectId je cudzi kluc, ktory pouzivame, akurat sa momentalne pri kazdom modeli vola inak. Napr pri DistrictChange sa vola DistrictChange.district_id a je naviazany na District.id. Pristup k objektu je potom DistrictChange#district_object.
changeId z XMLka je potom change_id, napr v Ra::DistrictChange.change_id -> Ra::Change.id. T.j. vsetky Ra::{District,Region,...}Change modely maju naviazanie na Ra::Change
There was a problem hiding this comment.
Aha, uz si spominam. Jasne. Moze byt.
|
@jsuchal Niektore atributy z XMLka nie su namapovane 1:1. Napr
Je to takto zamerne alebo to mam namapovat blizsie k tej originalnej scheme? |
|
@eronisko je to naschval, nech je Rails konvencia. |
It seems like they are not all unique.
config/application.rb
Outdated
| @@ -23,5 +24,6 @@ class Application < Rails::Application | |||
| # -- all .rb files in that directory are automatically loaded. | |||
|
|
|||
| config.active_record.schema_format = :sql | |||
| config.time_zone = "Europe/Bratislava" | |||
There was a problem hiding this comment.
Toto nie je dobry napad, my chceme aby app robila v UTC a ak chceme ine formaty, tak to uvedieme explicitne. Tvoja skusenost je aka?
There was a problem hiding this comment.
Pri registri adries chybaju casove zony a Rails pouzije pri Time.parse casovu zonu systemu na ktorom bezi. Tomu som sa chcel vyhnut, ale suhlasim ze mozno to nemalo ist az do globalneho configu. Na druhej strane, vacsina dat v harvestri bude zrejme specificka pre Slovensko, takze aj lokalna casova zona mi dava zmysel.
FWIW, data sa stale ukladaju v UTC. Ak ich chceme aj prezentovat v UTC, mozem ten config zrusit a byt explicitny len pri parsovani registra adries. Chces to radsej defaultne v UTC?
There was a problem hiding this comment.
Best practice pre api je mat vsetko v UTC. Cize dajme tak.
Use Bratislava timezone for Ra parsing only
Deleting the old module
|
@jsuchal spominal si ze tu este nieco treba, vies zistit ze co? |
|
Myslim, ze ked si pozries tu schemu tu tak moze byt ulica ktora prechadza
cez viac municipality a viac districts, neviem ci my to mame v modeli
zachytene. Ale neotvaral by som toto zatial, nemame na to uplne usecase.
…On Thu, Dec 21, 2017 at 11:38 PM Ernest Walzel ***@***.***> wrote:
@jsuchal <https://github.com/jsuchal> spominal si ze tu este nieco treba,
vies zistit ze co?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABm5uoC7C127VlMJCZmMBvrbWiaxu52ks5tCt4BgaJpZM4NPNwb>
.
|
|
Nasiel som taky lepsi endpoint na zmenove davky https://data.gov.sk/api/2/search/resource?name=zmenov%C3%A1%20d%C3%A1vka&all_fields=1&order_by=-last_modified |
Dokoncenie #1