You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Gaspard Bucher <ga...@teti.ch> on 2009/01/29 00:11:47 UTC
couchdb as backend for a CMS
Hi list !
I am investigating couchDB as a possible replacement for MySQL in a CMS.
Some reasons I think it could be good for the job:
1. STI (all objects in the CMS are sub-classes of Node)
2. dynamic attributes (a table stores key/value pairs)
3. no need for "content" tables attached to the main "nodes" table for
specialized content (image, contact)
Some reasons I think it would be tricky to use couchDB:
1. relations between nodes (these relations are defined through the
"links" table with a "relation_id" to define the type of link): no
idea how this could be implemented in couchDB
2. chained relations ("images from favorites from friends" ==> follow
two links (favorites, friends) and filter by class type (image)).
Sorry if this is a very common newbie question.
Some pictures of the data model: http://zenadmin.org/333
Gaspard
Re: couchdb as backend for a CMS
Posted by Gaspard Buma <ga...@gmail.com>.
I have already read the link. From what I understand, you cannot model
joins that depend on an external document (links table). This means no
"has and belongs to many".
On Thu, Jan 29, 2009 at 3:47 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 29 Jan 2009, at 00:11, Gaspard Bucher wrote:
>>
>> 1. relations between nodes (these relations are defined through the
>> "links" table with a "relation_id" to define the type of link): no
>> idea how this could be implemented in couchDB
>
>> 2. chained relations ("images from favorites from friends" ==> follow
>> two links (favorites, friends) and filter by class type (image)).
>
> http://wiki.apache.org/couchdb/Frequently_asked_questions#relationships
>
> Cheers
> Jan
> --
>
Re: couchdb as backend for a CMS
Posted by Jan Lehnardt <ja...@apache.org>.
On 29 Jan 2009, at 00:11, Gaspard Bucher wrote:
>
> 1. relations between nodes (these relations are defined through the
> "links" table with a "relation_id" to define the type of link): no
> idea how this could be implemented in couchDB
> 2. chained relations ("images from favorites from friends" ==> follow
> two links (favorites, friends) and filter by class type (image)).
http://wiki.apache.org/couchdb/Frequently_asked_questions#relationships
Cheers
Jan
--
Re: couchdb as backend for a CMS
Posted by Gaspard Buma <ga...@gmail.com>.
It's funny how the world goes around.... The "query" model in couchDB
is exactly what FileMaker has been forcing developers to use for more
then ten years:
Define calculation fields that act as multi-key indexes.
With clever hacks, I managed to build complete ERPs with FileMaker, so
I'm sure that couchDB could support the same kind of applications
(with added content flexibility and a better architecture) so the
concepts seem quite familiar.
If zena was a CMS with fixed relations (a post has comments, ...), it
would be a no brainer: couchDB would be a clear winner. But since an
important aspect of zena is the dynamic nature of the objects involved
and their relations (expressed with pseudo sql:
http://zenadmin.org/en/443) and since this is hard to model with views
I will continue to use a traditional RDMS until a database comes out
that supports both worlds (dynamic content definition with relational
queries).
Gaspard
On Thu, Jan 29, 2009 at 6:15 PM, Dean Landolt <de...@deanlandolt.com> wrote:
> On Thu, Jan 29, 2009 at 10:35 AM, Gaspard Buma <ga...@gmail.com>wrote:
>
>> But the example (comments in posts) is a "belongs_to" relation (no
>> need for an external join table). Is there any example with a "has
>> many and belongs to many" example ?
>>
>> My feeling is that a habtm relation could be modeled with something like:
>>
>> {
>> "name": "John",
>> "friends": ["Paul", "Mike", "Carla"]
>> }
>>
>> Then you index on friends:
>>
>> function(doc) {
>> doc.friends.map(function(friend) {
>> emit(friend, doc);
>> });
>> }
>>
>> That's fine (except you have to update "John" and "Carla" if they are
>> not friends anymore). But what if you move one level further and need
>> to see the latest posts of your friends ?
>>
>> {
>> "title": "Learning how to surf",
>> "author": "Carla"
>> }
>>
>> You can get the latest posts from "Carla" easily. You can get the list
>> of your friends easily, but you will have to manually loop through
>> your friends records in order to get the "latest posts from friends"
>> or maybe I am missing something important here...
>
>
> You're not. But what's the big deal? What you're describing can be done with
> two requests (the second being a multi-key get for latest post of each
> friend). I doubt you'll run into many issues unless the friends list is
> enormous, and I'm sure a better approach could be found.
>
Re: couchdb as backend for a CMS
Posted by Dean Landolt <de...@deanlandolt.com>.
On Thu, Jan 29, 2009 at 10:35 AM, Gaspard Buma <ga...@gmail.com>wrote:
> But the example (comments in posts) is a "belongs_to" relation (no
> need for an external join table). Is there any example with a "has
> many and belongs to many" example ?
>
> My feeling is that a habtm relation could be modeled with something like:
>
> {
> "name": "John",
> "friends": ["Paul", "Mike", "Carla"]
> }
>
> Then you index on friends:
>
> function(doc) {
> doc.friends.map(function(friend) {
> emit(friend, doc);
> });
> }
>
> That's fine (except you have to update "John" and "Carla" if they are
> not friends anymore). But what if you move one level further and need
> to see the latest posts of your friends ?
>
> {
> "title": "Learning how to surf",
> "author": "Carla"
> }
>
> You can get the latest posts from "Carla" easily. You can get the list
> of your friends easily, but you will have to manually loop through
> your friends records in order to get the "latest posts from friends"
> or maybe I am missing something important here...
You're not. But what's the big deal? What you're describing can be done with
two requests (the second being a multi-key get for latest post of each
friend). I doubt you'll run into many issues unless the friends list is
enormous, and I'm sure a better approach could be found.
Re: couchdb as backend for a CMS
Posted by Gaspard Buma <ga...@gmail.com>.
But the example (comments in posts) is a "belongs_to" relation (no
need for an external join table). Is there any example with a "has
many and belongs to many" example ?
My feeling is that a habtm relation could be modeled with something like:
{
"name": "John",
"friends": ["Paul", "Mike", "Carla"]
}
Then you index on friends:
function(doc) {
doc.friends.map(function(friend) {
emit(friend, doc);
});
}
That's fine (except you have to update "John" and "Carla" if they are
not friends anymore). But what if you move one level further and need
to see the latest posts of your friends ?
{
"title": "Learning how to surf",
"author": "Carla"
}
You can get the latest posts from "Carla" easily. You can get the list
of your friends easily, but you will have to manually loop through
your friends records in order to get the "latest posts from friends"
or maybe I am missing something important here...
Gaspard
On Thu, Jan 29, 2009 at 4:15 PM, Troy Kruthoff <tk...@blit.com> wrote:
> Gaspard,
>
> Couch can do it (the link Jan sent to Christopher's excellent blog post
> gives the details), but the key is that couch does it differently and it is
> not a drop in replacement for an RDBMS. From my experience, there is an
> initial learning curve where you have to un-RDBMS your brain and approach
> the solution from couch's perspective. In the process, I found that
> defining relationships with the power of a programming language (javascript,
> but you can use others) smokes the confined spaces of primary/secondary
> keys.
>
> -- troy
>
>
>
Re: couchdb as backend for a CMS
Posted by Troy Kruthoff <tk...@blit.com>.
Gaspard,
Couch can do it (the link Jan sent to Christopher's excellent blog
post gives the details), but the key is that couch does it differently
and it is not a drop in replacement for an RDBMS. From my experience,
there is an initial learning curve where you have to un-RDBMS your
brain and approach the solution from couch's perspective. In the
process, I found that defining relationships with the power of a
programming language (javascript, but you can use others) smokes the
confined spaces of primary/secondary keys.
-- troy
Re: couchdb as backend for a CMS
Posted by Gaspard Buma <ga...@gmail.com>.
I have been looking closer to couchDB and how it could *better*
replace MySQL. The main problem with MySQL is that the schema is
fixed. If you want to add attributes on some elements, you have to add
fields in the table or use an external table with "key" and "value"
fields (solution used actually).
Clearly the "storage is just a hash" approach of couchDB would solve
this issue very well. But there are other things that I really need.
For example "has and belong to many" through links. (nodes 1----*
links *----1 nodes).
Typical queries in zena include the same table (nodes) multiple times.
Currently, I do not see how this could be implemented with couchDB
views.
Example: the pseudo sql query "related_courses from pages in
assigned_jobs" gets translated into SQL that traverses the following
path:
nodes (Employee) 1 ---- * links (assigned_job) * ---- 1 nodes (Job) 1
--- [parent/child] --- * nodes (Page) --- links (related_courses) ---
nodes (Course)
In this (simplified real world) example, the "nodes" table is used 3
times (not counting context) and "links" is used 2 times.
I think this is hard to model in a RDBM and would be impossible with
something like couchDB.
Please tell me if I am wrong.
Gaspard
On Thu, Jan 29, 2009 at 3:18 PM, Rich Morin <rd...@cfcl.com> wrote:
> At 10:26 +0200 1/29/09, Dmitrii Dimandt wrote:
>> With any CMS/wiki you also have to handle complex ACLs
>
> I've been considering something like the model used by TWiki,
> where each page, web (aka namespace), and the wiki as a whole
> have access controls. Users and groups have permissions.
> It's a bit like a cross between Unix permissions and ACLs.
> I'd be happy to hear about other, better approaches...
>
>
> At 09:31 +0100 1/29/09, Gaspard Buma wrote:
>> Currently, I have absolutely no cue on how this access
>> management can be handled. Should all views contain
>> parameters for the list of groups the user is in ?
>
> CouchDB has some skeletal support for access controls, so it
> can enforce limitations, once they're codified. However,
> you'll need to create the higher-level infrastructure for
> tracking who's who, etc. I found this article helpful:
>
> http://jchris.mfdz.com/code/2008/12/couchdb_edge__security_and_vali
>
> -r
> --
> http://www.cfcl.com/rdm Rich Morin
> http://www.cfcl.com/rdm/resume rdm@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Technical editing and writing, programming, and web development
>
Re: couchdb as backend for a CMS
Posted by Rich Morin <rd...@cfcl.com>.
At 10:26 +0200 1/29/09, Dmitrii Dimandt wrote:
> With any CMS/wiki you also have to handle complex ACLs
I've been considering something like the model used by TWiki,
where each page, web (aka namespace), and the wiki as a whole
have access controls. Users and groups have permissions.
It's a bit like a cross between Unix permissions and ACLs.
I'd be happy to hear about other, better approaches...
At 09:31 +0100 1/29/09, Gaspard Buma wrote:
> Currently, I have absolutely no cue on how this access
> management can be handled. Should all views contain
> parameters for the list of groups the user is in ?
CouchDB has some skeletal support for access controls, so it
can enforce limitations, once they're codified. However,
you'll need to create the higher-level infrastructure for
tracking who's who, etc. I found this article helpful:
http://jchris.mfdz.com/code/2008/12/couchdb_edge__security_and_vali
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
Re: couchdb as backend for a CMS
Posted by Brian Candler <B....@pobox.com>.
On Thu, Jan 29, 2009 at 09:31:42AM +0100, Gaspard Buma wrote:
> I'll study couchDB a bit more in depth and will come back with some
> thoughts on the question. My primary concern right now is query speed
> and if I have to create a view for each and every find_by_sql.
Pretty much, although some finders may be able to share a view if you choose
your view keys carefully.
It's similar to creating indexes in SQL, except that a SQL engine can have a
stab at optimising a particular query based on whatever indexes it has
available, trying to do the best job it can. The actual results can vary
very much depending on how the engine works. I think couchdb will be a lot
more deterministic in this regard; what you get is more like a materialised
view.
Regards,
Brian.
Re: couchdb as backend for a CMS
Posted by Gaspard Buma <ga...@gmail.com>.
I'll study couchDB a bit more in depth and will come back with some
thoughts on the question. My primary concern right now is query speed
and if I have to create a view for each and every find_by_sql.
The other concern is (as noted by Dmitrii) access management. Zena
uses a group based access model on three layers (readers, writers,
publishers) + owner.
Currently, I have absolutely no cue on how this access management can
be handled. Should all views contain parameters for the list of groups
the user is in ?
Still learning the basics.
Gaspard
PS: if anyone has a link on couchDB examples for relation or access
modeling, please give a pointer.
On Thu, Jan 29, 2009 at 9:26 AM, Dmitrii Dimandt <dm...@gmail.com> wrote:
>
> On Jan 29, 2009, at 4:12 AM, Rich Morin wrote:
>
>> At 00:11 +0100 1/29/09, Gaspard Bucher wrote:
>>>
>>> I am investigating couchDB as a possible replacement
>>> for MySQL in a CMS.
>>
>> I am currently using CouchDB as the back end to a (very
>> experimental) wiki that has some CMS-like aspirations:
>>
>> http://cfcl.com/twiki/bin/view/Projects/Ontiki/WebHome
>> http://cfcl.com/twiki/bin/view/Projects/Ontiki/Examples
>>
>>
>> I would be delighted to share ideas with you (or anyone
>> else) about these sorts of issues. My impression is that
>> CouchDB can handle arbitrary relations, but that it won't
>> do so in anything like the manner used in an RDBMS.
>>
>>
>> FWIW, my approach to handling relations involves creating
>> documents that define certain kinds of abstract relations,
>> then declaring which role a tangible document plays in an
>> instance of a given relation type. Mind you, I haven't
>> coded up any of this yet (:-).
>>
>
>
> With any CMS/wiki you also have to handle complex ACLs
>
Re: couchdb as backend for a CMS
Posted by Dmitrii Dimandt <dm...@gmail.com>.
On Jan 29, 2009, at 4:12 AM, Rich Morin wrote:
> At 00:11 +0100 1/29/09, Gaspard Bucher wrote:
>> I am investigating couchDB as a possible replacement
>> for MySQL in a CMS.
>
> I am currently using CouchDB as the back end to a (very
> experimental) wiki that has some CMS-like aspirations:
>
> http://cfcl.com/twiki/bin/view/Projects/Ontiki/WebHome
> http://cfcl.com/twiki/bin/view/Projects/Ontiki/Examples
>
>
> I would be delighted to share ideas with you (or anyone
> else) about these sorts of issues. My impression is that
> CouchDB can handle arbitrary relations, but that it won't
> do so in anything like the manner used in an RDBMS.
>
>
> FWIW, my approach to handling relations involves creating
> documents that define certain kinds of abstract relations,
> then declaring which role a tangible document plays in an
> instance of a given relation type. Mind you, I haven't
> coded up any of this yet (:-).
>
With any CMS/wiki you also have to handle complex ACLs
Re: couchdb as backend for a CMS
Posted by Rich Morin <rd...@cfcl.com>.
At 00:11 +0100 1/29/09, Gaspard Bucher wrote:
> I am investigating couchDB as a possible replacement
> for MySQL in a CMS.
I am currently using CouchDB as the back end to a (very
experimental) wiki that has some CMS-like aspirations:
http://cfcl.com/twiki/bin/view/Projects/Ontiki/WebHome
http://cfcl.com/twiki/bin/view/Projects/Ontiki/Examples
I would be delighted to share ideas with you (or anyone
else) about these sorts of issues. My impression is that
CouchDB can handle arbitrary relations, but that it won't
do so in anything like the manner used in an RDBMS.
FWIW, my approach to handling relations involves creating
documents that define certain kinds of abstract relations,
then declaring which role a tangible document plays in an
instance of a given relation type. Mind you, I haven't
coded up any of this yet (:-).
-r
P.S. My approach is influenced by Object Role Modeling
and Conceptual Graphs, in that both systems use
N-ary relations, entities playing roles, etc.
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development