You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Christopher McComas <mc...@gmail.com> on 2008/12/16 20:46:35 UTC
General Q about CouchDB
I'm new to CouchDB, really think it'll open up a lot of exciting things for
me, and other developers.
So, since CouchDB is not a Relational database management system, would it
not be wise/recommended/whatever to use it for say the following setup?
(Note, coming from a relational background, along with PHP and now
python/django).
Say, we have a blog, a normal setup for a blog with Django would be:
TABLE blog
id
title
entry
date
categories (relational to 'category' table)
TABLE category
id
title
I think based on our above it'd make sense to use a MySQL, Postgres, etc db,
since it is a relation setup. One thing I've done though is added a 'link'
field to my blog, so that if I want to post a link, instead of a normal blog
entry I'd just enter the URL in that field, and my templates/HTML know that
if URL is not empty display it as a link to the external URL, as opposed to
the normal blog entry. I think this is where CouchDB would come into play,
so that for all of my entries I won't have either a blank link or entry
field taking up wasted space in the database, and CouchDB would be
perfection for this setup.
Would it be wrong to try to do the category piece as related in CouchDB?
What would be the best way to do it, so that you can have a page,
myblog.com/categories/this-category/ that'd then display all the entries for
that category? What would be proper?
Again, just really interested in this, trying to learn more about it, so it
can help my day job, and my fun side projects a lot nicer.
Thanks,
Chris
Re: General Q about CouchDB
Posted by Kerr Rainey <ke...@gmail.com>.
2008/12/17 Chris Anderson <jc...@gmail.com>:
>> If you need / want to maintain consistency at all times in the
>> database you can't do it with CouchDB.
>
> Just to clear up any misconceptions: all the updates in a _bulk_docs
> request succeed or fail atomically. So as long as you're working on a
> single node, it is possible to ensure consistency while eg: changing a
> user's link url across a selection of blog posts.
OK, yes, there are ways you could build a CouchDB application where
the database is always consistent. For example if no docs refer to
another in any way, then it will always be consistent. If you can
engineer your app so that all updates that might effect any reference
also updates all docs in that ref graph, then that should maintain the
integrity. But if you do that then you would get the same effect by
just using a single doc. But is that very useful?
I think it's useful to just get over the fact that the design
trade-offs will often come down to it being possible for the database
to be inconsistent and deal with that. I don't think this is a
problem, it's just an anathema if you come from RDBMS land.
--
Kerr
Re: General Q about CouchDB
Posted by Chris Anderson <jc...@gmail.com>.
On Wed, Dec 17, 2008 at 3:07 AM, Kerr Rainey <ke...@gmail.com> wrote:
> 2008/12/17 Andrea Schiavini <a....@sourcesense.com>:
>> In the second approach described in this article, posts are separated from
>> comments. But isn't this in contrast with the impossibility of CouchDB to
>> update atomically several documents? It could lead to a loss of database
>> integrity, if in example an user deletes an article while another one
>> updates a related comment. Shouldn't it be encouraged to keep related
>> informations in the same document?
>
> If you need / want to maintain consistency at all times in the
> database you can't do it with CouchDB.
Just to clear up any misconceptions: all the updates in a _bulk_docs
request succeed or fail atomically. So as long as you're working on a
single node, it is possible to ensure consistency while eg: changing a
user's link url across a selection of blog posts.
--
Chris Anderson
http://jchris.mfdz.com
Re: General Q about CouchDB
Posted by Kerr Rainey <ke...@gmail.com>.
2008/12/17 Andrea Schiavini <a....@sourcesense.com>:
> In the second approach described in this article, posts are separated from
> comments. But isn't this in contrast with the impossibility of CouchDB to
> update atomically several documents? It could lead to a loss of database
> integrity, if in example an user deletes an article while another one
> updates a related comment. Shouldn't it be encouraged to keep related
> informations in the same document?
If you need / want to maintain consistency at all times in the
database you can't do it with CouchDB. You need to let go of that
desire and focus on how things will work in practice. There is no
referential integrity, so you can end up with orphaned documents.
Does this matter in practice? How will it effect the application you
are writing?
In CouchDB you most definitely do not want to keep *all* related
information on the same document. This leads to massive contention on
that document. What if I have a blog post and attracts lots of
comments. I don't want the users to keep having to resubmit there
comments because the main post is getting updated with other comments.
The comment is related, but should not be part of the main post. I
could also have two replicas of the post on different servers. When
the post is replicated I don't want to have all the comments for one
version lost because they are part of the losing main post. If they
are separate documents both replicas will just get new copies of the
comments from the other server.
So what happens if a user deletes a main post while a user is posting
a comment? What will they see? Well, that depends on exactly what the
application layer does, but you should be able to engineer whatever
you would expect the same app backed by an RDBMS to do. The user
submits their comment then gets redirect back to the main blog post.
That has been deleted and they see a message saying the post doesn't
exist. In the backend there will be an orphan that will require
housekeeping to clean up. The application will require some
housekeeping functionality so that I can delete all comments for a
blog post when I delete the main post.
Personally I would love to see so integrity checking and housekeeping
functions built in to CouchDB's core. This wouldn't stop the database
getting into an inconstant state, but would provide provide automated
handling of common housekeeping tasks, like cascading deletes, so it
wouldn't have to be implemented ad nauseum at the application layer.
--
Kerr
Re: General Q about CouchDB
Posted by Andrea Schiavini <a....@sourcesense.com>.
In the second approach described in this article, posts are separated from
comments. But isn't this in contrast with the impossibility of CouchDB to
update atomically several documents? It could lead to a loss of database
integrity, if in example an user deletes an article while another one
updates a related comment. Shouldn't it be encouraged to keep related
informations in the same document?
Andrea Schiavini
2008/12/17 Jan Lehnardt <ja...@prima.de>
>
> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
>
> Chris,
>> Thanks. One question, concern I might have with that would be just
>> spelling
>> something differently, but that shouldn't be too big of an issue.
>>
>> To my next question, what would be the best way to structure comments for
>> a
>> blog post, where they have their own author, timestamp, and entry? Again,
>> this is fairly straight-forward with a relational db using a foreign key.
>>
>
> Same concept ;)
>
> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
>
> Cheers
> Jan
> --
>
>
>
>
>>
>> Thanks,
>>
>> On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com> wrote:
>>
>> On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
>>> <mc...@gmail.com> wrote:
>>>
>>>> Would it be wrong to try to do the category piece as related in CouchDB?
>>>> What would be the best way to do it, so that you can have a page,
>>>> myblog.com/categories/this-category/ that'd then display all the
>>>> entries
>>>>
>>> for
>>>
>>>> that category? What would be proper?
>>>>
>>>
>>> Having a category field on the blog post itself is a fine way to do this.
>>>
>>> Eg:
>>>
>>> {
>>> "title":"Blah",
>>> "author":"Chris",
>>> "category":"music",
>>> "date": ...
>>> }
>>>
>>> Writing a view that sorts posts by category and date would be simple
>>> with this sort of data structure. Of course if you wanted to rename a
>>> category later you'd need to touch all the documents that listed it,
>>> so this solution is more like tagging than categories, but should
>>> fulfill the need.
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchris.mfdz.com
>>>
>>>
>
Re: General Q about CouchDB
Posted by James Marca <jm...@translab.its.uci.edu>.
On Wed, Dec 17, 2008 at 02:43:54PM -0500, Paul Davis wrote:
> On Wed, Dec 17, 2008 at 2:18 PM, James Marca
> <jm...@translab.its.uci.edu> wrote:
> > On Wed, Dec 17, 2008 at 01:47:47PM -0500, Paul Davis wrote:
> >> James,
> >>
> >> Near as I know, it's not possible to do an arbitrary tree depth first
> >> tree sort only using a parent link. Someone may yet come up with a
> >> clever trick to do it, but for the moment no one has thought of a
> >> solution.
> >>
> >> You mention storing the entire path but also seem to discard the idea.
> >> Any reason. If you're in a threaded thinger like you got, then you
> >> would have access to the path of the node to which your replying. And
> >> the topology would be stable so no worries about moving paths etc.
> >> Having the full path should allow you to do what you want fairly
> >> easily. I think.
> >
> > Two reasons I am discounting storing the full path to the parent in
> > each node. First, if a node only knows its parent, then the parent
> > can move around and not put the node's data into conflict with the
> > parent's. If on the other hand the node knows its parent's path, then
> > if you move any node in the hierarchy, you have to fix all the
> > descendants' information as well. I am beginning to understand that
> > couchdb doesn't enforce consistent data (thanks mostly to the nifty
> > figure 2.1 in the draft book), so I'd rather not put stuff in there
> > that expects consistency and then needs to be maintained. Seems like
> > asking for trouble.
> >
>
> These are all valid points, but in terms of comments on a blog, how
> often are you going to re-parent nodes in the tree? Assuming you're
> not a fan of revisionist history, I'd guess never. Or even if you
> decide to go back and reengineer the document relations it would be in
> terms of writing scripts to transform the entire db at once.
Yes, well, my application isn't comments on a blog. I was trying not
to move the original topic too far!
>
> > Second, and more importantly to my sense of propriety as a programmer,
> > if every node underneath a parent stores the parent's path to the
> > root, that seems like a waste of resources. I'd rather skip the
> > sorting step altogether and do something else (like the rely on the
> > client to build the tree from well structured data, as in my prior
> > post).
> >
>
> Part of knowing the rules is knowing when to break them. While there
> would be overhead in terms of disk space, you're saving your self a
> ton of computation. This is one of the core tenants of the CouchDB
> philosophy.
>
In my app, my bottleneck *is* disk space. I'm writing new
computed results from raw data every 30 seconds from now to forever,
so of course I have to also roll along and delete older stuff, and
also allow for recreation of older stuff on demand if needed from the
original source data. If each node carries redundant data, I can
carry just a little bit less ancient history.
All the writing and deleting happens server side. The general use
clients only ask for data (that may or may not exist). Each data
point is independent of all others so couchdb is probably optimal (no
need for db-enforced consistency, and I gain high availability).
But each data source does exist in a physical, real world hierarchy.
That hierarchy doesn't change all that much, and I can hard code the
searches I use most, but I'm *also* trying to grok the limits of
couchdb while I build this app.
> > But, on the other hand, I *would* like to send a single query that can
> > fetch all comments under a specific comment. The start key/end key
> > hack with arrays as keys only seems to work if every doc can generate
> > an array with the same first element, second element, etc etc. I keep
> > thinking there might be a way to write out arrays in reverse order, or
> > maybe only keep the depth as a parameter inside of a doc and fill out
> > empty values or 'Z' for everything preceding depth -2 and depth-1 in
> > the sort array. But both seem to be dead ends.
> >
>
> It sure seems like it could almost be done, but the more I look at it
> the more that I think it could actually be prooven that it's
> impossible. The closest I've seen is getting a proper sort in N
> queries where N is the maximum depth of the tree. The logic is that to
probably N-1, but I agree. It seems like a 1 request sort would need
N-1 information already written, which perhaps is why the hack in the
blog page with just one level of depth (parent) works in one query.
> get a proper 1 request sort, each node needs to know where in the sort
> it needs to be. And AFAICT, this would be impossible without
> information on the full path to that node. This isn't to say that
> there might be some nifty method for storing that path information in
> constant space though.
>
> > Recursive queries are probably the only way to go, or maybe storing
> > the root post as well as the immediate parent in each "comment" type
> > doc, so that you can get all comments under a doc (which I want), and
> > take a rough stab at an initial sorting of any nested comments---the
> > jQuery type of solution I wrote earlier fails if you try to append a
> > node to a parent that doesn't yet exist.
> >
>
> The only issue with this though is that it doesn't work with paging.
> Whether that's a concern or not I don't know.
>
Not a concern of mine for my app. If I was doing a blog or otherwise
worried about paging long lists of data, I'd probably look at a
client-side data engine, like dojo's data stores. The initial pull
from the db would populate the data store, then the doc to doc
organization would be done within the store. while I've never used
them, I recall seeing a paging type of function in dojo's data
docs. Hmm, things have changed in dojo.land, but
http://docs.dojocampus.org/quickstart/data/usingdatastores/pagination
seems relevant.
My understanding of couchdb after writing this and thinking about the
docs I've read is that the fundamental design principle is that
documents are supposed to be independent. Otherwise, database
consistency becomes important. If documents rely only on local
information, all is well. If you bend or break this rule, you're
asking for trouble down the road and/or must plan for and write code
to clean up the messes that will eventually result. My app doesn't
*really* need join tables or data from other documents (for sorting,
etc), so the upshot for me is that I'm probably going to change my
current RDBMS-centric way of doing things.
>
> I've been dealing with a similar issue in regards to threading email
> list archives. I spent a bit of time reading up on different threading
> algorithms until I realized the answer to my question. There is no
> spoon.
>
> Thinking about it, the best two email UI's I've ever used are Gmail
> and MarkMail. Neither of which uses a hierarchical view. They each
> have single linear threads. that are arranged by time of arrival.
> Something in that tells me that the threading issue is really a
> 'insert euphemism that means non-issue'. I wouldn't doubt that there's
> a white paper out there that says as much.
>
well this is neither here nor there, but I use mutt, which I've set to
sort on threads and (secondary) reverse-date-received. Mostly that does
what I want.
Thanks for the comments
James
> HTH,
> Paul Davis
>
> >>
> >> Paul Davis
> >>
> >> On Wed, Dec 17, 2008 at 1:30 PM, James Marca
> >> <jm...@translab.its.uci.edu> wrote:
> >> > On Wed, Dec 17, 2008 at 01:49:20AM +0100, Jan Lehnardt wrote:
> >> >>
> >> >> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
> >> >>
> >> >> >Chris,
> >> >> >Thanks. One question, concern I might have with that would be just
> >> >> >spelling something differently, but that shouldn't be too big of an
> >> >> >issue.
> >> >> >
> >> >> >To my next question, what would be the best way to structure
> >> >> >comments for a blog post, where they have their own author,
> >> >> >timestamp, and entry? Again, this is fairly straight-forward with
> >> >> >a relational db using a foreign key.
> >> >>
> >> >> Same concept ;)
> >> >>
> >> >> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
> >> >>
> >> >
> >> > Apologies for forking a topic slightly, but this maps onto a problem I
> >> > am having. And apologies if this has been answered. I'm new here, I
> >> > *did* look, but I haven't a solution I like yet.
> >> >
> >> > The article's suggested solution will allow comments nested one-layer
> >> > deep. Am I missing something, or is it nearly impossible to collect
> >> > comments on comments in one go? My thought would be to replace "post"
> >> > with "parent", but then the view map can't build the sort order
> >> > properly, no?
> >> >
> >> > For example:
> >> >
> >> > {
> >> > "_id": "ABCDEF",
> >> > "_rev": "123456",
> >> > "type": "comment",
> >> > "post": "myslug",
> >> > "author": "jack",
> >> > "content": "…"}
> >> > }, {
> >> > "_id": "DEFABC",
> >> > "_rev": "123456",
> >> > "type": "comment",
> >> > "post": "myslug",
> >> > "parent": "myslug",
> >> > "author": "jane",
> >> > "content": "…"
> >> > }, {
> >> > "_id": "FABC1234",
> >> > "_rev": "123456",
> >> > "type": "comment",
> >> > "post": "myslug",
> >> > "parent": "DEFABC",
> >> > "author": "john",
> >> > "content": "…"
> >> > }
> >> >
> >> > Winging it with untested code, the best guess I can make for nested
> >> > sorting is something like:
> >> >
> >> > function(doc) {
> >> > if (doc.type == "post") {
> >> > emit([doc._id, 0], doc);
> >> > } else if (doc.type == "comment") {
> >> > if(doc.parent == null || doc.parent=doc.post){
> >> > // could have a date here for the second sort key?
> >> > emit([doc.post, doc._id, 1], doc);
> >> > }else{
> >> > // this fails for arbitrarily deep nesting.
> >> > emit([doc.post,doc.parent,doc._id],doc);
> >> > }
> >> > }
> >> > }
> >> >
> >> > As I understand it, the problem is that without storing the complete
> >> > hierarchy of comments, you can't reproduce the correct nested sorting
> >> > in one go. To quote the "how to store hierarchical data" page in the
> >> > wiki, "Store the full path to each node as an attribute in that node's
> >> > document."
> >> >
> >> > On the other hand, a perfectly valid solution that uses client-side
> >> > javascript to build the doc (this is a blog after all) would be to
> >> > just use dom functions to append to parents, something like
> >> >
> >> > jQuery.each(commentArray, function(){
> >> > jQuery("#"+this.parent)
> >> > .append("<div id='"+this._id+"'class='comment'>"
> >> > +this.content
> >> > +"</div>");
> >> > });
> >> >
> >> > While this makes it possible to nest comments on the page of
> >> > most browswers that support jQuery etc., my real question is about the
> >> > inner workings of couchdb, whether it is possible to make the sort
> >> > with some clever view definition trickery.
> >> >
> >> > Note that I have absolutely zero clue about reduce functions and their
> >> > uses. Maybe you can use reduce to generate arbitrarily deep nesting
> >> > of comments with just a "parent" field??
> >> >
> >> > James
> >> >
> >> >> Cheers
> >> >> Jan
> >> >> --
> >> >>
> >> >>
> >> >> >
> >> >> >
> >> >> >Thanks,
> >> >> >
> >> >> >On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
> >> >> >wrote:
> >> >> >
> >> >> >>On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
> >> >> >><mc...@gmail.com> wrote:
> >> >> >>>Would it be wrong to try to do the category piece as related in
> >> >> >>>CouchDB?
> >> >> >>>What would be the best way to do it, so that you can have a page,
> >> >> >>>myblog.com/categories/this-category/ that'd then display all the
> >> >> >>>entries
> >> >> >>for
> >> >> >>>that category? What would be proper?
> >> >> >>
> >> >> >>Having a category field on the blog post itself is a fine way to do
> >> >> >>this.
> >> >> >>
> >> >> >>Eg:
> >> >> >>
> >> >> >>{
> >> >> >>"title":"Blah",
> >> >> >>"author":"Chris",
> >> >> >>"category":"music",
> >> >> >>"date": ...
> >> >> >>}
> >> >> >>
> >> >> >>Writing a view that sorts posts by category and date would be simple
> >> >> >>with this sort of data structure. Of course if you wanted to rename a
> >> >> >>category later you'd need to touch all the documents that listed it,
> >> >> >>so this solution is more like tagging than categories, but should
> >> >> >>fulfill the need.
> >> >> >>
> >> >> >>
> >> >> >>--
> >> >> >>Chris Anderson
> >> >> >>http://jchris.mfdz.com
> >> >> >>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: General Q about CouchDB
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Dec 17, 2008 at 2:18 PM, James Marca
<jm...@translab.its.uci.edu> wrote:
> On Wed, Dec 17, 2008 at 01:47:47PM -0500, Paul Davis wrote:
>> James,
>>
>> Near as I know, it's not possible to do an arbitrary tree depth first
>> tree sort only using a parent link. Someone may yet come up with a
>> clever trick to do it, but for the moment no one has thought of a
>> solution.
>>
>> You mention storing the entire path but also seem to discard the idea.
>> Any reason. If you're in a threaded thinger like you got, then you
>> would have access to the path of the node to which your replying. And
>> the topology would be stable so no worries about moving paths etc.
>> Having the full path should allow you to do what you want fairly
>> easily. I think.
>
> Two reasons I am discounting storing the full path to the parent in
> each node. First, if a node only knows its parent, then the parent
> can move around and not put the node's data into conflict with the
> parent's. If on the other hand the node knows its parent's path, then
> if you move any node in the hierarchy, you have to fix all the
> descendants' information as well. I am beginning to understand that
> couchdb doesn't enforce consistent data (thanks mostly to the nifty
> figure 2.1 in the draft book), so I'd rather not put stuff in there
> that expects consistency and then needs to be maintained. Seems like
> asking for trouble.
>
These are all valid points, but in terms of comments on a blog, how
often are you going to re-parent nodes in the tree? Assuming you're
not a fan of revisionist history, I'd guess never. Or even if you
decide to go back and reengineer the document relations it would be in
terms of writing scripts to transform the entire db at once.
> Second, and more importantly to my sense of propriety as a programmer,
> if every node underneath a parent stores the parent's path to the
> root, that seems like a waste of resources. I'd rather skip the
> sorting step altogether and do something else (like the rely on the
> client to build the tree from well structured data, as in my prior
> post).
>
Part of knowing the rules is knowing when to break them. While there
would be overhead in terms of disk space, you're saving your self a
ton of computation. This is one of the core tenants of the CouchDB
philosophy.
> But, on the other hand, I *would* like to send a single query that can
> fetch all comments under a specific comment. The start key/end key
> hack with arrays as keys only seems to work if every doc can generate
> an array with the same first element, second element, etc etc. I keep
> thinking there might be a way to write out arrays in reverse order, or
> maybe only keep the depth as a parameter inside of a doc and fill out
> empty values or 'Z' for everything preceding depth -2 and depth-1 in
> the sort array. But both seem to be dead ends.
>
It sure seems like it could almost be done, but the more I look at it
the more that I think it could actually be prooven that it's
impossible. The closest I've seen is getting a proper sort in N
queries where N is the maximum depth of the tree. The logic is that to
get a proper 1 request sort, each node needs to know where in the sort
it needs to be. And AFAICT, this would be impossible without
information on the full path to that node. This isn't to say that
there might be some nifty method for storing that path information in
constant space though.
> Recursive queries are probably the only way to go, or maybe storing
> the root post as well as the immediate parent in each "comment" type
> doc, so that you can get all comments under a doc (which I want), and
> take a rough stab at an initial sorting of any nested comments---the
> jQuery type of solution I wrote earlier fails if you try to append a
> node to a parent that doesn't yet exist.
>
The only issue with this though is that it doesn't work with paging.
Whether that's a concern or not I don't know.
> James
>
I've been dealing with a similar issue in regards to threading email
list archives. I spent a bit of time reading up on different threading
algorithms until I realized the answer to my question. There is no
spoon.
Thinking about it, the best two email UI's I've ever used are Gmail
and MarkMail. Neither of which uses a hierarchical view. They each
have single linear threads. that are arranged by time of arrival.
Something in that tells me that the threading issue is really a
'insert euphemism that means non-issue'. I wouldn't doubt that there's
a white paper out there that says as much.
HTH,
Paul Davis
>>
>> Paul Davis
>>
>> On Wed, Dec 17, 2008 at 1:30 PM, James Marca
>> <jm...@translab.its.uci.edu> wrote:
>> > On Wed, Dec 17, 2008 at 01:49:20AM +0100, Jan Lehnardt wrote:
>> >>
>> >> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
>> >>
>> >> >Chris,
>> >> >Thanks. One question, concern I might have with that would be just
>> >> >spelling something differently, but that shouldn't be too big of an
>> >> >issue.
>> >> >
>> >> >To my next question, what would be the best way to structure
>> >> >comments for a blog post, where they have their own author,
>> >> >timestamp, and entry? Again, this is fairly straight-forward with
>> >> >a relational db using a foreign key.
>> >>
>> >> Same concept ;)
>> >>
>> >> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
>> >>
>> >
>> > Apologies for forking a topic slightly, but this maps onto a problem I
>> > am having. And apologies if this has been answered. I'm new here, I
>> > *did* look, but I haven't a solution I like yet.
>> >
>> > The article's suggested solution will allow comments nested one-layer
>> > deep. Am I missing something, or is it nearly impossible to collect
>> > comments on comments in one go? My thought would be to replace "post"
>> > with "parent", but then the view map can't build the sort order
>> > properly, no?
>> >
>> > For example:
>> >
>> > {
>> > "_id": "ABCDEF",
>> > "_rev": "123456",
>> > "type": "comment",
>> > "post": "myslug",
>> > "author": "jack",
>> > "content": "…"}
>> > }, {
>> > "_id": "DEFABC",
>> > "_rev": "123456",
>> > "type": "comment",
>> > "post": "myslug",
>> > "parent": "myslug",
>> > "author": "jane",
>> > "content": "…"
>> > }, {
>> > "_id": "FABC1234",
>> > "_rev": "123456",
>> > "type": "comment",
>> > "post": "myslug",
>> > "parent": "DEFABC",
>> > "author": "john",
>> > "content": "…"
>> > }
>> >
>> > Winging it with untested code, the best guess I can make for nested
>> > sorting is something like:
>> >
>> > function(doc) {
>> > if (doc.type == "post") {
>> > emit([doc._id, 0], doc);
>> > } else if (doc.type == "comment") {
>> > if(doc.parent == null || doc.parent=doc.post){
>> > // could have a date here for the second sort key?
>> > emit([doc.post, doc._id, 1], doc);
>> > }else{
>> > // this fails for arbitrarily deep nesting.
>> > emit([doc.post,doc.parent,doc._id],doc);
>> > }
>> > }
>> > }
>> >
>> > As I understand it, the problem is that without storing the complete
>> > hierarchy of comments, you can't reproduce the correct nested sorting
>> > in one go. To quote the "how to store hierarchical data" page in the
>> > wiki, "Store the full path to each node as an attribute in that node's
>> > document."
>> >
>> > On the other hand, a perfectly valid solution that uses client-side
>> > javascript to build the doc (this is a blog after all) would be to
>> > just use dom functions to append to parents, something like
>> >
>> > jQuery.each(commentArray, function(){
>> > jQuery("#"+this.parent)
>> > .append("<div id='"+this._id+"'class='comment'>"
>> > +this.content
>> > +"</div>");
>> > });
>> >
>> > While this makes it possible to nest comments on the page of
>> > most browswers that support jQuery etc., my real question is about the
>> > inner workings of couchdb, whether it is possible to make the sort
>> > with some clever view definition trickery.
>> >
>> > Note that I have absolutely zero clue about reduce functions and their
>> > uses. Maybe you can use reduce to generate arbitrarily deep nesting
>> > of comments with just a "parent" field??
>> >
>> > James
>> >
>> >> Cheers
>> >> Jan
>> >> --
>> >>
>> >>
>> >> >
>> >> >
>> >> >Thanks,
>> >> >
>> >> >On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
>> >> >wrote:
>> >> >
>> >> >>On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
>> >> >><mc...@gmail.com> wrote:
>> >> >>>Would it be wrong to try to do the category piece as related in
>> >> >>>CouchDB?
>> >> >>>What would be the best way to do it, so that you can have a page,
>> >> >>>myblog.com/categories/this-category/ that'd then display all the
>> >> >>>entries
>> >> >>for
>> >> >>>that category? What would be proper?
>> >> >>
>> >> >>Having a category field on the blog post itself is a fine way to do
>> >> >>this.
>> >> >>
>> >> >>Eg:
>> >> >>
>> >> >>{
>> >> >>"title":"Blah",
>> >> >>"author":"Chris",
>> >> >>"category":"music",
>> >> >>"date": ...
>> >> >>}
>> >> >>
>> >> >>Writing a view that sorts posts by category and date would be simple
>> >> >>with this sort of data structure. Of course if you wanted to rename a
>> >> >>category later you'd need to touch all the documents that listed it,
>> >> >>so this solution is more like tagging than categories, but should
>> >> >>fulfill the need.
>> >> >>
>> >> >>
>> >> >>--
>> >> >>Chris Anderson
>> >> >>http://jchris.mfdz.com
>> >> >>
>> >
>> > --
>> > This message has been scanned for viruses and
>> > dangerous content by MailScanner, and is
>> > believed to be clean.
>> >
>> >
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
Re: General Q about CouchDB
Posted by James Marca <jm...@translab.its.uci.edu>.
On Wed, Dec 17, 2008 at 01:47:47PM -0500, Paul Davis wrote:
> James,
>
> Near as I know, it's not possible to do an arbitrary tree depth first
> tree sort only using a parent link. Someone may yet come up with a
> clever trick to do it, but for the moment no one has thought of a
> solution.
>
> You mention storing the entire path but also seem to discard the idea.
> Any reason. If you're in a threaded thinger like you got, then you
> would have access to the path of the node to which your replying. And
> the topology would be stable so no worries about moving paths etc.
> Having the full path should allow you to do what you want fairly
> easily. I think.
Two reasons I am discounting storing the full path to the parent in
each node. First, if a node only knows its parent, then the parent
can move around and not put the node's data into conflict with the
parent's. If on the other hand the node knows its parent's path, then
if you move any node in the hierarchy, you have to fix all the
descendants' information as well. I am beginning to understand that
couchdb doesn't enforce consistent data (thanks mostly to the nifty
figure 2.1 in the draft book), so I'd rather not put stuff in there
that expects consistency and then needs to be maintained. Seems like
asking for trouble.
Second, and more importantly to my sense of propriety as a programmer,
if every node underneath a parent stores the parent's path to the
root, that seems like a waste of resources. I'd rather skip the
sorting step altogether and do something else (like the rely on the
client to build the tree from well structured data, as in my prior
post).
But, on the other hand, I *would* like to send a single query that can
fetch all comments under a specific comment. The start key/end key
hack with arrays as keys only seems to work if every doc can generate
an array with the same first element, second element, etc etc. I keep
thinking there might be a way to write out arrays in reverse order, or
maybe only keep the depth as a parameter inside of a doc and fill out
empty values or 'Z' for everything preceding depth -2 and depth-1 in
the sort array. But both seem to be dead ends.
Recursive queries are probably the only way to go, or maybe storing
the root post as well as the immediate parent in each "comment" type
doc, so that you can get all comments under a doc (which I want), and
take a rough stab at an initial sorting of any nested comments---the
jQuery type of solution I wrote earlier fails if you try to append a
node to a parent that doesn't yet exist.
James
>
> Paul Davis
>
> On Wed, Dec 17, 2008 at 1:30 PM, James Marca
> <jm...@translab.its.uci.edu> wrote:
> > On Wed, Dec 17, 2008 at 01:49:20AM +0100, Jan Lehnardt wrote:
> >>
> >> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
> >>
> >> >Chris,
> >> >Thanks. One question, concern I might have with that would be just
> >> >spelling something differently, but that shouldn't be too big of an
> >> >issue.
> >> >
> >> >To my next question, what would be the best way to structure
> >> >comments for a blog post, where they have their own author,
> >> >timestamp, and entry? Again, this is fairly straight-forward with
> >> >a relational db using a foreign key.
> >>
> >> Same concept ;)
> >>
> >> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
> >>
> >
> > Apologies for forking a topic slightly, but this maps onto a problem I
> > am having. And apologies if this has been answered. I'm new here, I
> > *did* look, but I haven't a solution I like yet.
> >
> > The article's suggested solution will allow comments nested one-layer
> > deep. Am I missing something, or is it nearly impossible to collect
> > comments on comments in one go? My thought would be to replace "post"
> > with "parent", but then the view map can't build the sort order
> > properly, no?
> >
> > For example:
> >
> > {
> > "_id": "ABCDEF",
> > "_rev": "123456",
> > "type": "comment",
> > "post": "myslug",
> > "author": "jack",
> > "content": "…"}
> > }, {
> > "_id": "DEFABC",
> > "_rev": "123456",
> > "type": "comment",
> > "post": "myslug",
> > "parent": "myslug",
> > "author": "jane",
> > "content": "…"
> > }, {
> > "_id": "FABC1234",
> > "_rev": "123456",
> > "type": "comment",
> > "post": "myslug",
> > "parent": "DEFABC",
> > "author": "john",
> > "content": "…"
> > }
> >
> > Winging it with untested code, the best guess I can make for nested
> > sorting is something like:
> >
> > function(doc) {
> > if (doc.type == "post") {
> > emit([doc._id, 0], doc);
> > } else if (doc.type == "comment") {
> > if(doc.parent == null || doc.parent=doc.post){
> > // could have a date here for the second sort key?
> > emit([doc.post, doc._id, 1], doc);
> > }else{
> > // this fails for arbitrarily deep nesting.
> > emit([doc.post,doc.parent,doc._id],doc);
> > }
> > }
> > }
> >
> > As I understand it, the problem is that without storing the complete
> > hierarchy of comments, you can't reproduce the correct nested sorting
> > in one go. To quote the "how to store hierarchical data" page in the
> > wiki, "Store the full path to each node as an attribute in that node's
> > document."
> >
> > On the other hand, a perfectly valid solution that uses client-side
> > javascript to build the doc (this is a blog after all) would be to
> > just use dom functions to append to parents, something like
> >
> > jQuery.each(commentArray, function(){
> > jQuery("#"+this.parent)
> > .append("<div id='"+this._id+"'class='comment'>"
> > +this.content
> > +"</div>");
> > });
> >
> > While this makes it possible to nest comments on the page of
> > most browswers that support jQuery etc., my real question is about the
> > inner workings of couchdb, whether it is possible to make the sort
> > with some clever view definition trickery.
> >
> > Note that I have absolutely zero clue about reduce functions and their
> > uses. Maybe you can use reduce to generate arbitrarily deep nesting
> > of comments with just a "parent" field??
> >
> > James
> >
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >> >
> >> >
> >> >Thanks,
> >> >
> >> >On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
> >> >wrote:
> >> >
> >> >>On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
> >> >><mc...@gmail.com> wrote:
> >> >>>Would it be wrong to try to do the category piece as related in
> >> >>>CouchDB?
> >> >>>What would be the best way to do it, so that you can have a page,
> >> >>>myblog.com/categories/this-category/ that'd then display all the
> >> >>>entries
> >> >>for
> >> >>>that category? What would be proper?
> >> >>
> >> >>Having a category field on the blog post itself is a fine way to do
> >> >>this.
> >> >>
> >> >>Eg:
> >> >>
> >> >>{
> >> >>"title":"Blah",
> >> >>"author":"Chris",
> >> >>"category":"music",
> >> >>"date": ...
> >> >>}
> >> >>
> >> >>Writing a view that sorts posts by category and date would be simple
> >> >>with this sort of data structure. Of course if you wanted to rename a
> >> >>category later you'd need to touch all the documents that listed it,
> >> >>so this solution is more like tagging than categories, but should
> >> >>fulfill the need.
> >> >>
> >> >>
> >> >>--
> >> >>Chris Anderson
> >> >>http://jchris.mfdz.com
> >> >>
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: General Q about CouchDB
Posted by Paul Davis <pa...@gmail.com>.
James,
Near as I know, it's not possible to do an arbitrary tree depth first
tree sort only using a parent link. Someone may yet come up with a
clever trick to do it, but for the moment no one has thought of a
solution.
You mention storing the entire path but also seem to discard the idea.
Any reason. If you're in a threaded thinger like you got, then you
would have access to the path of the node to which your replying. And
the topology would be stable so no worries about moving paths etc.
Having the full path should allow you to do what you want fairly
easily. I think.
Paul Davis
On Wed, Dec 17, 2008 at 1:30 PM, James Marca
<jm...@translab.its.uci.edu> wrote:
> On Wed, Dec 17, 2008 at 01:49:20AM +0100, Jan Lehnardt wrote:
>>
>> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
>>
>> >Chris,
>> >Thanks. One question, concern I might have with that would be just
>> >spelling something differently, but that shouldn't be too big of an
>> >issue.
>> >
>> >To my next question, what would be the best way to structure
>> >comments for a blog post, where they have their own author,
>> >timestamp, and entry? Again, this is fairly straight-forward with
>> >a relational db using a foreign key.
>>
>> Same concept ;)
>>
>> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
>>
>
> Apologies for forking a topic slightly, but this maps onto a problem I
> am having. And apologies if this has been answered. I'm new here, I
> *did* look, but I haven't a solution I like yet.
>
> The article's suggested solution will allow comments nested one-layer
> deep. Am I missing something, or is it nearly impossible to collect
> comments on comments in one go? My thought would be to replace "post"
> with "parent", but then the view map can't build the sort order
> properly, no?
>
> For example:
>
> {
> "_id": "ABCDEF",
> "_rev": "123456",
> "type": "comment",
> "post": "myslug",
> "author": "jack",
> "content": "…"}
> }, {
> "_id": "DEFABC",
> "_rev": "123456",
> "type": "comment",
> "post": "myslug",
> "parent": "myslug",
> "author": "jane",
> "content": "…"
> }, {
> "_id": "FABC1234",
> "_rev": "123456",
> "type": "comment",
> "post": "myslug",
> "parent": "DEFABC",
> "author": "john",
> "content": "…"
> }
>
> Winging it with untested code, the best guess I can make for nested
> sorting is something like:
>
> function(doc) {
> if (doc.type == "post") {
> emit([doc._id, 0], doc);
> } else if (doc.type == "comment") {
> if(doc.parent == null || doc.parent=doc.post){
> // could have a date here for the second sort key?
> emit([doc.post, doc._id, 1], doc);
> }else{
> // this fails for arbitrarily deep nesting.
> emit([doc.post,doc.parent,doc._id],doc);
> }
> }
> }
>
> As I understand it, the problem is that without storing the complete
> hierarchy of comments, you can't reproduce the correct nested sorting
> in one go. To quote the "how to store hierarchical data" page in the
> wiki, "Store the full path to each node as an attribute in that node's
> document."
>
> On the other hand, a perfectly valid solution that uses client-side
> javascript to build the doc (this is a blog after all) would be to
> just use dom functions to append to parents, something like
>
> jQuery.each(commentArray, function(){
> jQuery("#"+this.parent)
> .append("<div id='"+this._id+"'class='comment'>"
> +this.content
> +"</div>");
> });
>
> While this makes it possible to nest comments on the page of
> most browswers that support jQuery etc., my real question is about the
> inner workings of couchdb, whether it is possible to make the sort
> with some clever view definition trickery.
>
> Note that I have absolutely zero clue about reduce functions and their
> uses. Maybe you can use reduce to generate arbitrarily deep nesting
> of comments with just a "parent" field??
>
> James
>
>> Cheers
>> Jan
>> --
>>
>>
>> >
>> >
>> >Thanks,
>> >
>> >On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
>> >wrote:
>> >
>> >>On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
>> >><mc...@gmail.com> wrote:
>> >>>Would it be wrong to try to do the category piece as related in
>> >>>CouchDB?
>> >>>What would be the best way to do it, so that you can have a page,
>> >>>myblog.com/categories/this-category/ that'd then display all the
>> >>>entries
>> >>for
>> >>>that category? What would be proper?
>> >>
>> >>Having a category field on the blog post itself is a fine way to do
>> >>this.
>> >>
>> >>Eg:
>> >>
>> >>{
>> >>"title":"Blah",
>> >>"author":"Chris",
>> >>"category":"music",
>> >>"date": ...
>> >>}
>> >>
>> >>Writing a view that sorts posts by category and date would be simple
>> >>with this sort of data structure. Of course if you wanted to rename a
>> >>category later you'd need to touch all the documents that listed it,
>> >>so this solution is more like tagging than categories, but should
>> >>fulfill the need.
>> >>
>> >>
>> >>--
>> >>Chris Anderson
>> >>http://jchris.mfdz.com
>> >>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
Re: General Q about CouchDB
Posted by James Marca <jm...@translab.its.uci.edu>.
On Wed, Dec 17, 2008 at 01:49:20AM +0100, Jan Lehnardt wrote:
>
> On 16 Dec 2008, at 20:54, Christopher McComas wrote:
>
> >Chris,
> >Thanks. One question, concern I might have with that would be just
> >spelling something differently, but that shouldn't be too big of an
> >issue.
> >
> >To my next question, what would be the best way to structure
> >comments for a blog post, where they have their own author,
> >timestamp, and entry? Again, this is fairly straight-forward with
> >a relational db using a foreign key.
>
> Same concept ;)
>
> See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
>
Apologies for forking a topic slightly, but this maps onto a problem I
am having. And apologies if this has been answered. I'm new here, I
*did* look, but I haven't a solution I like yet.
The article's suggested solution will allow comments nested one-layer
deep. Am I missing something, or is it nearly impossible to collect
comments on comments in one go? My thought would be to replace "post"
with "parent", but then the view map can't build the sort order
properly, no?
For example:
{
"_id": "ABCDEF",
"_rev": "123456",
"type": "comment",
"post": "myslug",
"author": "jack",
"content": "…"}
}, {
"_id": "DEFABC",
"_rev": "123456",
"type": "comment",
"post": "myslug",
"parent": "myslug",
"author": "jane",
"content": "…"
}, {
"_id": "FABC1234",
"_rev": "123456",
"type": "comment",
"post": "myslug",
"parent": "DEFABC",
"author": "john",
"content": "…"
}
Winging it with untested code, the best guess I can make for nested
sorting is something like:
function(doc) {
if (doc.type == "post") {
emit([doc._id, 0], doc);
} else if (doc.type == "comment") {
if(doc.parent == null || doc.parent=doc.post){
// could have a date here for the second sort key?
emit([doc.post, doc._id, 1], doc);
}else{
// this fails for arbitrarily deep nesting.
emit([doc.post,doc.parent,doc._id],doc);
}
}
}
As I understand it, the problem is that without storing the complete
hierarchy of comments, you can't reproduce the correct nested sorting
in one go. To quote the "how to store hierarchical data" page in the
wiki, "Store the full path to each node as an attribute in that node's
document."
On the other hand, a perfectly valid solution that uses client-side
javascript to build the doc (this is a blog after all) would be to
just use dom functions to append to parents, something like
jQuery.each(commentArray, function(){
jQuery("#"+this.parent)
.append("<div id='"+this._id+"'class='comment'>"
+this.content
+"</div>");
});
While this makes it possible to nest comments on the page of
most browswers that support jQuery etc., my real question is about the
inner workings of couchdb, whether it is possible to make the sort
with some clever view definition trickery.
Note that I have absolutely zero clue about reduce functions and their
uses. Maybe you can use reduce to generate arbitrarily deep nesting
of comments with just a "parent" field??
James
> Cheers
> Jan
> --
>
>
> >
> >
> >Thanks,
> >
> >On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
> >wrote:
> >
> >>On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
> >><mc...@gmail.com> wrote:
> >>>Would it be wrong to try to do the category piece as related in
> >>>CouchDB?
> >>>What would be the best way to do it, so that you can have a page,
> >>>myblog.com/categories/this-category/ that'd then display all the
> >>>entries
> >>for
> >>>that category? What would be proper?
> >>
> >>Having a category field on the blog post itself is a fine way to do
> >>this.
> >>
> >>Eg:
> >>
> >>{
> >>"title":"Blah",
> >>"author":"Chris",
> >>"category":"music",
> >>"date": ...
> >>}
> >>
> >>Writing a view that sorts posts by category and date would be simple
> >>with this sort of data structure. Of course if you wanted to rename a
> >>category later you'd need to touch all the documents that listed it,
> >>so this solution is more like tagging than categories, but should
> >>fulfill the need.
> >>
> >>
> >>--
> >>Chris Anderson
> >>http://jchris.mfdz.com
> >>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: General Q about CouchDB
Posted by Jan Lehnardt <ja...@prima.de>.
On 16 Dec 2008, at 20:54, Christopher McComas wrote:
> Chris,
> Thanks. One question, concern I might have with that would be just
> spelling
> something differently, but that shouldn't be too big of an issue.
>
> To my next question, what would be the best way to structure
> comments for a
> blog post, where they have their own author, timestamp, and entry?
> Again,
> this is fairly straight-forward with a relational db using a foreign
> key.
Same concept ;)
See http://www.cmlenz.net/archives/2007/10/couchdb-joins for details.
Cheers
Jan
--
>
>
> Thanks,
>
> On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com>
> wrote:
>
>> On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
>> <mc...@gmail.com> wrote:
>>> Would it be wrong to try to do the category piece as related in
>>> CouchDB?
>>> What would be the best way to do it, so that you can have a page,
>>> myblog.com/categories/this-category/ that'd then display all the
>>> entries
>> for
>>> that category? What would be proper?
>>
>> Having a category field on the blog post itself is a fine way to do
>> this.
>>
>> Eg:
>>
>> {
>> "title":"Blah",
>> "author":"Chris",
>> "category":"music",
>> "date": ...
>> }
>>
>> Writing a view that sorts posts by category and date would be simple
>> with this sort of data structure. Of course if you wanted to rename a
>> category later you'd need to touch all the documents that listed it,
>> so this solution is more like tagging than categories, but should
>> fulfill the need.
>>
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>>
Re: General Q about CouchDB
Posted by Domingo Aguilera <do...@gmail.com>.
http://batok.blogspot.com/2008/09/new-attachment-handling-in-couchdb.html
On Tue, Dec 16, 2008 at 1:54 PM, Christopher McComas <
mccomas.chris@gmail.com> wrote:
> Chris,
> Thanks. One question, concern I might have with that would be just spelling
> something differently, but that shouldn't be too big of an issue.
>
> To my next question, what would be the best way to structure comments for a
> blog post, where they have their own author, timestamp, and entry? Again,
> this is fairly straight-forward with a relational db using a foreign key.
>
> Thanks,
>
> On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com> wrote:
>
> > On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
> > <mc...@gmail.com> wrote:
> > > Would it be wrong to try to do the category piece as related in
> CouchDB?
> > > What would be the best way to do it, so that you can have a page,
> > > myblog.com/categories/this-category/ that'd then display all the
> entries
> > for
> > > that category? What would be proper?
> >
> > Having a category field on the blog post itself is a fine way to do this.
> >
> > Eg:
> >
> > {
> > "title":"Blah",
> > "author":"Chris",
> > "category":"music",
> > "date": ...
> > }
> >
> > Writing a view that sorts posts by category and date would be simple
> > with this sort of data structure. Of course if you wanted to rename a
> > category later you'd need to touch all the documents that listed it,
> > so this solution is more like tagging than categories, but should
> > fulfill the need.
> >
> >
> > --
> > Chris Anderson
> > http://jchris.mfdz.com
> >
>
Re: General Q about CouchDB
Posted by Christopher McComas <mc...@gmail.com>.
Chris,
Thanks. One question, concern I might have with that would be just spelling
something differently, but that shouldn't be too big of an issue.
To my next question, what would be the best way to structure comments for a
blog post, where they have their own author, timestamp, and entry? Again,
this is fairly straight-forward with a relational db using a foreign key.
Thanks,
On Tue, Dec 16, 2008 at 2:51 PM, Chris Anderson <jc...@gmail.com> wrote:
> On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
> <mc...@gmail.com> wrote:
> > Would it be wrong to try to do the category piece as related in CouchDB?
> > What would be the best way to do it, so that you can have a page,
> > myblog.com/categories/this-category/ that'd then display all the entries
> for
> > that category? What would be proper?
>
> Having a category field on the blog post itself is a fine way to do this.
>
> Eg:
>
> {
> "title":"Blah",
> "author":"Chris",
> "category":"music",
> "date": ...
> }
>
> Writing a view that sorts posts by category and date would be simple
> with this sort of data structure. Of course if you wanted to rename a
> category later you'd need to touch all the documents that listed it,
> so this solution is more like tagging than categories, but should
> fulfill the need.
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: General Q about CouchDB
Posted by Chris Anderson <jc...@gmail.com>.
On Tue, Dec 16, 2008 at 11:46 AM, Christopher McComas
<mc...@gmail.com> wrote:
> Would it be wrong to try to do the category piece as related in CouchDB?
> What would be the best way to do it, so that you can have a page,
> myblog.com/categories/this-category/ that'd then display all the entries for
> that category? What would be proper?
Having a category field on the blog post itself is a fine way to do this.
Eg:
{
"title":"Blah",
"author":"Chris",
"category":"music",
"date": ...
}
Writing a view that sorts posts by category and date would be simple
with this sort of data structure. Of course if you wanted to rename a
category later you'd need to touch all the documents that listed it,
so this solution is more like tagging than categories, but should
fulfill the need.
--
Chris Anderson
http://jchris.mfdz.com