Mikseri.net

#2 kirjoitettu 29.12.2002 20:59

Mainostettu? Joopajoo, lähinnä kiinnostaisi tietää minkä hemmetin takia noi muiden kommentit meni mun biisiin.

#3 kirjoitettu 29.12.2002 21:08

Mistä päättelet ettei kommentit ole sinun biisille tarkoitettu?

#4 kirjoitettu 29.12.2002 22:02

Niin juuri. kyllä tuo vaikutti ihan sun biisille suunnatulta.. Hiphoppari joka ei ymmärtänyt ambientin päälle ollenkaan.. en vaivautunut biisiäsi kuuntelemaan mutta jos se ei oo siit tykänny ni miks ei sais antaa nelosta..? Lapsellista touhuahan tuollainen - arvioida nelosella biisiä jota ei tajua mutta ei siitä tänne tarvitsisi alkaa älähtämään.. tuollaisella topicilla vielä.

#5 kirjoitettu 29.12.2002 22:04

no toi on tuttu tilanne... siis ite oon kommentoinut jotain biisiä huomatakseni myöhemmin että ihan eri biisiin on kommentti lähtenyt. Tietysti ei voi näin jatkua, mutta luulen että johtuu siitä kun joku ottaa biisin pois niin biisin koodi siirtyy toiselle. Ja kommenttit samalla jos ne kirjoittaa biisin poistuttua.

#6 kirjoitettu 29.12.2002 22:14

Keskusteltuani toisen näistä "hoppareista" kanssa, kuulin homman menneen näin: tyyppi oli kommentoinut toisen tyypin biisiä (siis toisen "hopparin" ) ja kommentti oli tullut myös mun biisiin, joka oli just lisätty. Mikä bugaa? Kommentit eivät siis olleet mun biisille osoitettuja, ne kun oli tulleet _heti_ kun mun biisi oli lisätty.

#7 kirjoitettu 29.12.2002 22:23

maraz kirjoitti:
Keskusteltuani toisen näistä "hoppareista" kanssa, kuulin homman menneen näin: tyyppi oli kommentoinut toisen tyypin biisiä (siis toisen "hopparin" ) ja kommentti oli tullut myös mun biisiin, joka oli just lisätty. Mikä bugaa? Kommentit eivät siis olleet mun biisille osoitettuja, ne kun oli tulleet _heti_ kun mun biisi oli lisätty.


keroppa kuka tämä toinen hoppari on niin asiaa voisi ehkä selvittääkkin.

#8 kirjoitettu 29.12.2002 22:50

OoCee kirjoitti:
keroppa kuka tämä toinen hoppari on niin asiaa voisi ehkä selvittääkkin.


Äkkiähän tuo olisi tuolta sivulta selvinnyt...

KullanKaivajat ja Colli olivat siis asialla.

#9 kirjoitettu 29.12.2002 22:59

Itse törmäsin samaan ongelmaan joskus Mikserin ensimmäisen version aikoihin, mutta kuvittelin ongelman korjaantuneen tässä viimeisimpien versioiden aikana. Ongelman aiheuttaa käsittääkseni se, että alkuperäisesti kommentit saanut kappale on poistettu ja tämän kappaleen tunnusnumero on vapautunut. Seuraava Mikseriin lähetetty kappale puolestaan ottaa tuon tyhjän paikan käyttöönsä ja saa automaattisesti saman tunnusnumeron omaavan biisin kommentit ja arvosanat, vaikkei niitä ole juuri tälle samaiselle kappaleelle annettu.

Näin ainakin olen kuvitellut järjestelmän toimivan, mutten ole aivan varma. Voi asia toki olla toisinkin. Ape varmaan tietää varmemmin.

#10 kirjoitettu 29.12.2002 23:11

Ei vaikuttaisi niin olevan, kun noi tyypit olivat just kommentoineet toistensa? kappaleita tai jotain sinnepäin. Mutta kivaa kuitenkin että joku ottaa asiasta selvää, tai ainakin yrittää.

#11 kirjoitettu 30.12.2002 00:12

Tuo Killin esittämä mysql:n käyttäytyminen vaikuttaisi järkevimmältä selitykseltä. Tietääkös joku, saako tuon mysql:n käyttäytymään niin, ettei samaa id:tä käytetä uudelleen, vaikka se vapautuisikin?

Ape muokkasi viestiä 00:17 30.12.2002

#12 kirjoitettu 30.12.2002 00:49

Ape kirjoitti:
Tietääkös joku, saako tuon mysql:n käyttäytymään niin, ettei samaa id:tä käytetä uudelleen, vaikka se vapautuisikin?


Mutru the Great Guru suositteli, että laitat sille ID-kentälle auto_incrementin.

#13 kirjoitettu 30.12.2002 00:55

Mulla on käynyt noin parikin kertaa. Olen kommentoinut biisiä, sitten se on samalla hetkellä poistettu ja mennyt toiselle biisille joka tuli tämän poistetun biisin tilalle, tuossa uudet biisit listassa. Hirvee haukkuminen tullut, ja sitten menny kattoo: "hups, tuli ihan oikeesti väärälle biisille". Ja olen toinen jäsen Kullankaivajista ja epäilenpä että tässä tapauksessa on käyny juuri noin.

#14 kirjoitettu 30.12.2002 00:57

maraz kirjoitti:
Mutru the Great Guru suositteli, että laitat sille ID-kentälle auto_incrementin.


Tuohan siellä jo luonnollisesti onkin. Käsittääkseni homma on kuitenkin niin, että jos uusin id poistetaan, niin se vapautuu käyttöön, jolloin tulee näitä ongelmia. En ole ihan 100% varma, mutta kokemusten perusteella on noin ainakin joskus käynyt..?

#15 kirjoitettu 30.12.2002 01:07

Ape kirjoitti:
maraz kirjoitti:
Mutru the Great Guru suositteli, että laitat sille ID-kentälle auto_incrementin.

Tuohan siellä jo luonnollisesti onkin. Käsittääkseni homma on kuitenkin niin, että jos uusin id poistetaan, niin se vapautuu käyttöön, jolloin tulee näitä ongelmia. En ole ihan 100% varma, mutta kokemusten perusteella on noin ainakin joskus käynyt..?


Mutru the Great Guru suositteli, että kanzis pitää laskuri erillään taulun sisällöstä.

#16 kirjoitettu 30.12.2002 07:07

Ape kirjoitti:
maraz kirjoitti:
Mutru the Great Guru suositteli, että laitat sille ID-kentälle auto_incrementin.


Tuohan siellä jo luonnollisesti onkin. Käsittääkseni homma on kuitenkin niin, että jos uusin id poistetaan, niin se vapautuu käyttöön, jolloin tulee näitä ongelmia. En ole ihan 100% varma, mutta kokemusten perusteella on noin ainakin joskus käynyt..?



Jees, noin siinä käypi. Henk.koht. en käytä auto-increment kenttiä kyllä viittauksina, juuri tuon uudelleen numeroinnin takia (taitaapa Access kannoissa mennä id:t uusiksi jos vetää compactin kannalle.. mysql:sta en tiedä). Erillinne id taulu voisi olla hyvä. Kun tarvitsee id, niin ottaa sieltä seuraavan vapaan ja ottaa sen käyttöön. Nykyisellään homman korjaus vaatinee jonkun verran kannan muokkausta. Uusien biisien lisäys siksi aikaa vaikka pois käytöstä, ettei mene sekaisin (no on siinä ne lock toiminnot..).

#17 kirjoitettu 30.12.2002 10:06

Itse käytän yleensä lähes joka taulussa ns. tila kenttää, joka voi olla vaikka numero/boolean kenttä tyyliin 0 = poistettu, 1 = aktiivinen. Ja sitten aina näytetään vain ne, missä tila on 1. Eräajolla poistetaan (jos poistetaan) ne rivit, mitkä on tilassa 0 (ja esim. tässä tapauksessa ID on pienempi kuin MAX(ID), mikä vähentää päällekkäisyyksien riskiä).

En kyllä ymmärrä miksi tuo on siltikään mahdollista, sillä jos kommenttirivi poistetaan taulusta, niin eikös siinä ole viittaus biisiin? eli kun rivi poistetaan poistuu luonnollisesti myös viittaus, joten ei ole väliä vaikka uusi luotaisiin samalla ID:llä, sillä viittauskenttä voi osoittaa ainoastaan yhteen kommenttitietueeseen kerrallaan.

Tilanne tietysti muuttuu, jos käytetään erillistä referenssitaulua, mikä tässä tapauksessa on turhaa. Tai sitten jos biisi poistetaan ja luodaan uusi samalla ID:llä, mutta luonnollisestihan poistettavaan tietueeseen liittyvä muu data tulisi poistaa myös.

Valitettavasti MySQL ei vissiin vielä tue triggereitä, mikä voisi helpottaa pitämään datat nipussa.

Yleisesti kanta kannattaa suunnitella niin, ettei päällekkäisyyksiä voi tulla ja samalla yritetään pitää taulujen määrä mahd. vähäisenä, eli ei turhia referenssitauluja, sillä vaikka kivoja ovatkin ne hankaloittavat joskus tiedon eheyden säilyttämistä, puhumattakaan monimutkaisista hauista jotka suodatetaan useiden referenssitasojen läpi.

Yksi vinkki on myös se, että älä käytä auto incrementtiä, sillä integerikin loppuu joskus (heh joo, 1000 vuoden päästä), vaan kannattaa käyttää esim. GUIDeja primary keynä (Globally Unique Identifier) jos se on kyseisessä ympäristössä mahdollista. GUID on yksilöllinen tunniste, joka teoriassa on aina globaalisti uniikki.


Jezmilar viilasi viestiä 10:08 30.12.2002

Mark Vera: Olet oikeassa, MySQL hakee autoincrement-kentän maksimiarvon ja lisää siihen yhden. Kyseinen kenttä siis pitää oikeastaan olla vielä indeksoitukin jos meinaa pitää homman tehokkaana.

Muilla "järeillä" kannoilla se ei joko toimi näin tai on asetettavissa.

Jezmilar sääti viestiä 23:35 30.12.2002

#18 kirjoitettu 31.12.2002 01:51

Jezmilar kirjoitti:
Itse käytän yleensä lähes joka taulussa ns. tila kenttää, joka voi olla vaikka numero/boolean kenttä tyyliin 0 = poistettu, 1 = aktiivinen. Ja sitten aina näytetään vain ne, missä tila on 1. Eräajolla poistetaan (jos poistetaan) ne rivit, mitkä on tilassa 0 (ja esim. tässä tapauksessa ID on pienempi kuin MAX(ID), mikä vähentää päällekkäisyyksien riskiä).


Tuo onki suht näppärä ratkaisu. Toimisi tässä vallan mainiosti. Tosin vaatisi korjauksia/muutoksia aika moneen paikkaa sql kyselyissä (?) eikä vain uuden rivin luonnissa.

En kyllä ymmärrä miksi tuo on siltikään mahdollista, sillä jos kommenttirivi poistetaan taulusta, niin eikös siinä ole viittaus biisiin? eli kun rivi poistetaan poistuu luonnollisesti myös viittaus, joten ei ole väliä vaikka uusi luotaisiin samalla ID:llä, sillä viittauskenttä voi osoittaa ainoastaan yhteen kommenttitietueeseen kerrallaan.


Ongelmahan lienee tämä:

1. sivulla on biisi ID:llä 100.
2. joku kirjoittaa kommenttia biisille, sivun formissa on viite tähän numeroon 100.
3. biisi id 100 poistetaan sillä aikaa, kun joku kirjoittaa kommenttia. Nyt viimeinen käytetty id on 99.
4. joku lisää uuden biisin ja tuo biisi saa numeron 100 ID:ksi (seuraava 99:sta, eli sama kuin äsken poistetulla biisillä).
5. kommentin kirjoittaja lähettää kommenttinsa. Koska uusi biisi lisättiin kirjoituksen aikana, sivun formin id 100 viite käsitellään tämä toisen, juuri lisätyn, biisin id:nä.
6. kommentti on väärällä biisillä.

Tilanne tietysti muuttuu, jos käytetään erillistä referenssitaulua, mikä tässä tapauksessa on turhaa. Tai sitten jos biisi poistetaan ja luodaan uusi samalla ID:llä, mutta luonnollisestihan poistettavaan tietueeseen liittyvä muu data tulisi poistaa myös.


Näin varmasti tapahtuukin, mutta ongelma on tuo tuossa yllä.

Yleisesti kanta kannattaa suunnitella niin, ettei päällekkäisyyksiä voi tulla ja samalla yritetään pitää taulujen määrä mahd. vähäisenä, eli ei turhia referenssitauluja, sillä vaikka kivoja ovatkin ne hankaloittavat joskus tiedon eheyden säilyttämistä, puhumattakaan monimutkaisista hauista jotka suodatetaan useiden referenssitasojen läpi.


Lähinnä nyt oli kyseessä taulusta missä olisi tieto "seuraavat vapaat id numerot", eikä käytettäisi esim. taulun viimeisestä id:stä seuraava, tai auto-incrementtiä (mikä mysql:ssä ottaa juuri viimeisen käytetystä id:stä seuraavan). Ts. kun uusi biisi lisätään, otetaan lock "seuraavat vapaat id numerot"-tauluun, kasvatetaan laskuria ja unlock. Sitten biisille annetaan tämä id (ei autoincrement kenttä). autoincrement kenttä voi olla esim. luontijärjestys kenttänä.

Tällä tavalla voisi myös kehittää id:n uudelleen käytön, mutta se tuskin tulee ajankohtaiseksi ainakaan ihan vielä, kun 32-bittisen id:n maksimi on se päälle 4 miljardia.. Tuossa vaiheessa apella olisi jo ongelmia biisien säilytystilasta

#19 kirjoitettu 31.12.2002 10:17

Mark Vera kirjoitti:

Ongelmahan lienee tämä:
1...
...6.


No, tuo selvensi, kiitos.

Lähinnä nyt oli kyseessä taulusta missä olisi tieto "seuraavat vapaat id numerot", eikä käytettäisi esim. taulun viimeisestä id:stä seuraava, tai auto-incrementtiä (mikä mysql:ssä ottaa juuri viimeisen käytetystä id:stä seuraavan). Ts. kun uusi biisi lisätään, otetaan lock "seuraavat vapaat id numerot"-tauluun, kasvatetaan laskuria ja unlock. Sitten biisille annetaan tämä id (ei autoincrement kenttä). autoincrement kenttä voi olla esim. luontijärjestys kenttänä.

Tällä tavalla voisi myös kehittää id:n uudelleen käytön, mutta se tuskin tulee ajankohtaiseksi ainakaan ihan vielä, kun 32-bittisen id:n maksimi on se päälle 4 miljardia.. Tuossa vaiheessa apella olisi jo ongelmia biisien säilytystilasta


Joo, tuokin on oikein hyvä ratkaisu. Sama taulu voi sitten palvella muiden taulujen ID-tarpeita. Tuossa varmaan kannattaisi pienen aliohjelman kirjoittaminen, jota kutsuttaisiin sitten tyyliin AnnaUusiID(<KohdeTaulu>. Aliohjelma hoitaisi tuon ID hanskailun, niin ei tarttis siitä välittää, ja menis sitten aina oikein. Jos mahdollista, lukitseminen kannattaa hoitaa rivitasolla.

Kyllä tuo 32-bittinen kokonaisluku tosiaan mikserin tarpeisiin varmasti riittää. Jos yksi ID varataan joka sekunti, 32bit integerin kapasiteetti loppuu 136 vuoden päästä, heh. Joskus tulee kuitenkin tarpeita, milloin sekään ei riitä tai jos ID:n tulee olla uniikki laajemmassa kontekstissa kuin yksi taulu.

#20 kirjoitettu 31.12.2002 12:13

Noni, nyt meillä on ratkasu ongelmaan, ja tarvitaan vielä ape korjaamaan. hophop

#21 kirjoitettu 31.12.2002 12:26

Mehän ollaan mukavia, kun keksitään Apelle lisää tekemistä. Kuitenkin slööbailee jossain sohvanpohjalla...

#22 kirjoitettu 31.12.2002 13:52

Jezmilar kirjoitti:
Mehän ollaan mukavia, kun keksitään Apelle lisää tekemistä. Kuitenkin slööbailee jossain sohvanpohjalla...


Eiku syön tällä hetkellä aamupalaksi limppua ja kahvia (soffalla).

Hyvää uutta vuotta ja kiitos noista ideoista, ois hyvä jos nuo sais ennen inttiä vielä hoidettua vaikka kuntoon..

#23 kirjoitettu 01.01.2003 18:45

Lowridah 187 kirjoitti:
Taas se tapahtui. Yöllä kommentoin kaverin biisiä, jonka se poisti melkein samantien. Äsken näin uuden biisin, menin kattomaan mitä siitä oltiin sanottu, ja perkele, mun kommentti oli siel minkä olin yöl laittanu kaverille.

Lowridah 187 muokkasi viestiä 14:40 01.01.2003



Jos joku on niin idiootti että käyttää mikseriä väliaikaisena säilytyspaikkana niin huh.. Kannattaisi varmasti sellaisen henkilön mainita se biisin infossa jotta kukaan menisi sitten sitä kommentoimaan ja tälläisiä päällekkäisyyksiä ei tapahtuisi.. biisi vaikka se olisikin väliaikainen näkyy kuitenkin aina etusivulla ja joku sen sieltä bongaa vaikka lukisikin "Älä kuuntele" tms. Hankkikaa webbiin säilytystilaa - ei sitä mikseriä tuohon ole tarkoitettu!

Jos tuollainen päällekkäisyys sattuu jostain muusta syystä - esim ylläpidon poistaessa biisejä niin se on eri asia.
MV & Jez, miksi Apen pitäisi korjata ongelma tuolla tavalla ? eikö yksinkertaisempaa olisi vain biisin poistettaessa jättää poistettu ID pois käytöstä.. vaikka varata se. Vai onko edes mahdollista ? En tunne noita asioita josta puhutte, mutta ajattelin että tuo voisi olla yksinkertaisempaa.. imo..

#24 kirjoitettu 23.03.2003 15:37

Red kirjoitti:
Jos joku on niin idiootti että käyttää mikseriä väliaikaisena säilytyspaikkana niin huh..

Ei ole kyllä järkeä siinäkään, että jollain on 100 biisiä sivullaan kesältä 2001. Turhaa Mikserin täyttöä. Voi niitä aina välillä poistaa parempien/uudempien tieltä, koska muisti ei varmaankaan ole ilmaista.