wk voetbalpool: dag 27

 
11 mei 2010

CouchDB gedraagt zich raar. Omdat het onze bedoeling was om toch steeds maar een enkele revisie te gebruiken, deleten we eerst de al bestaande. De manier waarop CouchDB dat doet is door …een nieuwe revisie aan te maken. Deze krijgt dan een lege inhoud en een statusvlaggetje ‘verwijderd’, zodat als je hem opvraagt je een HTTP 404 krijgt. De ‘doc_del_count’ gaat dan ook braaf één omhoog, maar zodra je een nieuw document onder dezelfde oude id opslaat, dan krijgt die echter weer een opvolgend revisienummer en gaat de ‘doc_del_count’ weer omlaag.

Maar toch klopt het niet helemaal. Bij het experimenteren vanaf de command-line (curl is je vriend) zie ik inderdaad gestaag oplopende revisienummers: opslaan, revisie 1. Verwijderen, revisie 2. Opslaan, revisie 3. Verwijderen, revisie 4. Opslaan, revisie 5. Enzovoort. En de driver in het back-end ziet inderdaad na wat experimenteren ook revisie 75 als nieuwste. Maar bij het verwijderen en vervolgens weer opslaan staat de teller ineens weer op 1. En als ik dan weer vanaf de command-line verwijder is dat rev.2, maar toevoegen krijgt ineens toch weer revisie 76. En ook in het back-end komen de ‘hogere’ nummers nu af en toe tevoorschijn. En ik kom er maar niet achter waar het verschil in ligt. Ook als ik vanaf de command-line naar het aantal oude revisies vraag is het antwoord eerst ‘dit is de enige’ maar komen na het verwijderen en weer toevoegen vervolgens toch ook weer nummers 1 t/m 75 tevoorschijn.

Maar sowieso lijkt het niet erg makkelijk (dwz. met een enkele database-query) om erachter te komen hoeveel revisies er nou zijn geweest en weer zijn afgeschreven. Je krijgt alleen het aantal verwijderde documenten te zien, en dat blijft keurig netjes nul, omdat we eigenlijk nergens actoren met persistente state weer uit de lucht halen. Dus uiteindelijk blijft de makkelijkste oplossing om domweg in de driver bij te houden hoeveel persistentie-acties er zijn geweest, en als dat een bepaalde drempelwaarde bereikt, de zaak te comprimeren.

Op andere plekken gaat de ontwikkeling gelukkig nog wel vooruit. Er worden nu ook mails gestuurd naar de groepseigenaar dat er mensen van zijn groep lid willen worden, en naar de aanvrager als die toegelaten of afgewezen wordt. De oorspronkelijke lijst met punten voor het front-end is al bijna volledig afgestreept, maar tijdens het werken komt Christa steeds weer dingetjes tegen die net niet lekker werken. De lijst met TODO’s blijft dus even lang qua aantal, maar qua grootte van de punten wordt het gelukkig wel steeds kleiner.

Simon is ondertussen wel ongelukkig met ons gebruik van GWT, en met de manier waarop CSS in elkaar zit. De web-applicatie is nu geheel in GWT gebouwd, waardoor er eigenlijk alleen een lege index.html bestaat waar de verschillende panelen dynamisch in worden geladen. GWT zet niet van zichzelf overal stijl-classes of id’s bij, en bouwt soms ingewikkelde table-constructies waar met CSS niet veel meer aan te veranderen is en waarvan de verschillende sub-elementen moeilijk met CSS te benaderen zijn. Dat maakt het stylen van de website op sommige momenten nogal een monnikenwerk, en ook nog eens zonder dat het resultaat precies is wat hij wil zien. Hetzelfde probleem speelt in de mobiele website, waar weliswaar geen GWT is gebruikt, maar waar CSS toch nog steeds niet flexibel genoeg is om de dingen precies naar wens te kunnen structureren. Een mooie les voor een volgend project. En ook het indexeren door zoekmachines wordt op deze manier lastig, omdat de index.html alleen een klein beetje franje bevat, terwijl de echte inhoud door javascript wordt verzorgd – en daar doen de indexeer-robots niet aan, dus die zien dat niet. Ook iets om een volgende keer aan te denken.

En daarmee wordt het half zes, en alles is wel.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development