search

TIM-JYU / TIM

TIM (The Interactive Material) is an open-source cloud-based platform for creating interactive learning documents.
https://tim.education/view/about/en-US
MIT License
13 stars 4 forks source link

Vaihtoehtoisten emailien tallennus #1986

Closed dezhidki closed 2 years ago

dezhidki commented 3 years ago

In GitLab by @Smibu on Sep 29, 2020, 11:10

Sisu-rajapinta kuulemma tukisi käyttäjän kaikkien emailien ilmoittamista.

Tim voisi tallentaa käyttäjän kaikki emailit ja sitten käyttäjä voisi valita, mikä niistä on pääosoite (siis osoite, johon Tim lähettää postin).

Järkevä toteutustapa lienee uusi taulu useraccount_email, johon tallentuisi kaikki emailit (myös pääosoite). Pääosoite olisi lisäksi useraccount-taulussa kuten nykyäänkin, jolloin postinlähetyslogiikkaan yms. asioihin ei tarvitse kajota.

dezhidki commented 3 years ago

In GitLab by @vesal on Sep 29, 2020, 11:23

Kannattaisiko tämä miettiä hieman laajemmin samalla. Eli luokittelisi tuollaisia henkilökohtaisia tietoja kuten:

email
puhno
facebook-osoite
twitter-osoite
kotisivu
osoite  (tuli tarve tällekin kun pitää lähettää luentomonisteita)

jne mitä mieleen tulee. Eli olisko taulussa tunniste tuolle pääluokalle (jotka on lueteltu omassa taulussa) ja sitten tuo arvo. Ensimmäisessä vaiheessa tietysti olisi vain noita email-arvoja. Mutta tavoitteena se, että jos tulee uusia tarpeita, niin ne olisivat vain tietokantamuutoksia. Esim Korpissa oli käytössä tuollainen systeemi. Sitten ehkä jsrunnerissa ja makroissa voisi viitata jotenkin noihinkin.

dezhidki commented 3 years ago

In GitLab by @Smibu on Sep 29, 2020, 11:53

Joo kenties. Tuohon liittyy joitain reunatapauksia. Esim kahdella käyttäjällä voi olla sama osoite, jos ovat kämppiksiä tms., jolloin taulussa oleva unique constraint (tuplella (category_id, value)) rajoittaisi liikaa.

dezhidki commented 3 years ago

In GitLab by @vesal on Sep 29, 2020, 11:57

Ainoa rajoite varmaan olisi että userid, tyyppiid, arvo on yksikäsitteinen. Tosiaan arvoisko voisi kuvitteellisesti tulla vaikka ammattinimkkeitä, sotilasarvoja yms. Vai pitäisi sitten olla kaksi taulua jossa toisessa arvojenkin pitäisi olla yksikäsitteisiä. Se voisi hankaloittaa kyllä käyttö yleisesti. Sitten voi tulle vielä oikeusjuttuja että kuka saa mitäkin arvoa nähdä, mutta se menisi ehkä sen tyyppitaulun kautta?

dezhidki commented 3 years ago

In GitLab by @Smibu on Sep 29, 2020, 12:11

Ainoa rajoite varmaan olisi että userid, tyyppiid, arvo on yksikäsitteinen.

Sehän ei sopisi emaileille. Ei kai kahdella eri käyttäjällä saa olla samaa emailia?

dezhidki commented 3 years ago

In GitLab by @vesal on Sep 29, 2020, 12:28

Voisiko tyyppitauluun laittaa vaatimuksen, että tästä on tarkistettava?

dezhidki commented 3 years ago

In GitLab by @Smibu on Sep 29, 2020, 12:57

En heti keksi onnistuisiko sellainen.

dezhidki commented 3 years ago

In GitLab by @vesal on Sep 29, 2020, 13:03

Se ei tietenkään onnistu tietokannan tasolla, mutta jos operaatiot saisi atomaarisiksi, niin tietoa tallentaessa katsottaisiin onko tyyppitaulussa yksikäsitteisyysvaatimus ja jos on, niin ennen tallennusta katsottaisiin ettei vastaavaa arvoa vielä ole. Pieni riskihän tuossa olisi yhtäaikaisissa tilanteissa voisi päästä kaksi samaa arvoa. Toki sen kaksi eri taulua voisi haudata ehkä sellaisen rajapinnan taakse, että käyttäjän ei tarvitse välittää kummastako taulusta hakee, eli jos on

 save_extra_attribute(userid, typeid, "vesal@jyu.fi)

niin typeid:n perusteella valitaan kumpaanko tauluun tallennetaan

Ja sitten

get_extra_attribute(userid, typeid)

hakee oikeasta taulusta. Ja silloin tietokanta voi pitää huolen yksikäsitteisyydestä.

dezhidki commented 2 years ago

Mergetty MRssä !253