Engage / ArtifactView / Comments / Storing documents in couchdb and other things

[Joan Garcia Vila]

Hi all.Recently I've posted an alpha implementation of the Database component (which has to become, I suppose, a subcomponent of ArtifactComments [server side]).Needs a conceptual review.- Talking about storing data on couchdb, this has been my first approach:            //  Artifact Comment  example.            var artifactComment = {};            artifactComment.engage_type = "artifact-comment";            artifactComment.artifact_id = "00311f0d3f5456c91934e472b880e9c5";            artifactComment.insertDate = "2009-11-30";            artifactComment.name = "Juan";            artifactComment.location = "Barcelona, Catalonia, Spain";            artifactComment.abuse = false;            artifactComment.info = "Barcelona is a beautiful mediterranian city.";There are few essential key points to check (understand / validate / talk about):1.- This document has a field that identifies its type ("engage_type").  If we store different object types inside the same database this will help and give higher scores in lucene fulltext search if we add the document type in the query (Please see/run the example).2 .- This document has a reference to another document. See field "artifact_id". Important to have good views with high selectivity.This will help us to create "in-server" high speed paged queries. Views for each document type if we need this functionality.(Please see/run the example).3.- The object also gets its _id and _rev attributes after it has been stored. This is coherent with couchdb (object oriented database) and the key is an uuid.(Please see/run the example).
4.- Data attributes is stored as a fixed text with pattern "YYYY-MM-DD".This will help us to have date sorted field views.5.- One important thing is that having the documents (2 diferent types) inside the same database allows us to create fast views (see Database.js).We can also create "pseudo joins" [complex views using map/reduce _design functions]- Other things that come to my mind, while developing the component, are:1. - How do we know who we are?, I haven't see a login page in the wireframes. But there is behaviour that seems to depend on knowing who we are. Like report abuse or delete, for an example.makes sense?2.- How do we know that the user is the moderator?makes sense?Cheers,joanps: you can find (Database. [js/html] on scratchpad/bug-parade.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091201/743ca9c7/attachment.htm>