incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Himes <dhi...@vlesolutions.com>
Subject Re: CouchDB namespace mechanism
Date Tue, 19 Oct 2010 14:52:55 GMT
Could you not also put them in subdirectories by including a '/' (%2F)
in their names?  Warning:  It's likely that I do not understand this
properly.

Dan

On Tue, 2010-10-19 at 15:09 +0100, Simon Metson wrote:

> Or put each type of data in it's own database, without knowing what  
> you want to do with the different documents it's hard to say  
> definitively. If you need to deal with your name spaced data at the  
> same time (which I guess from your example you do) then a view is the  
> way to go, if they're orthogonal to one another (you need to store  
> three unrelated, distinct data types) then a separate DB is the way to  
> go.
> Cheers
> Simon
> 
> On 19 Oct 2010, at 13:48, Wout Mertens wrote:
> 
> > You need to create views: http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views
> >
> > Cheers,
> >
> > Wout.
> >
> > On Oct 19, 2010, at 14:42 , Alex Ivasyuv wrote:
> >
> >> Hi,
> >>
> >> I faced an issue, with different types of documents in CouchDB.
> >> For example, I have 3 types of doc in DB:
> >>
> >> list-1
> >> list-2
> >> list-3
> >>
> >> tag-1
> >> tag-2
> >> tag-3
> >>
> >> user-1
> >> user-2
> >> user-3
> >>
> >> And issue for me, that they are lie in one layer, e.g. http://localhost:5984/mydb/

> >> <here all docs>
> >>
> >> Is there any mechanism to decoupled them into different layers,  
> >> e.g. namespace or something else:
> >>
> >> {user: [user-1: {...}]}
> >> {lists: [list-1, list-2, ...]}
> >>
> >> where user and list - namespaces for documents.
> >>
> >> Seems like I wrong understood the paradigm of NoSQL and CouchDB as  
> >> instance.
> >>
> >> Thanks in advance,
> >>
> >>
> >
> 



Daniel E. Himes, Ph.D.
President
Virtual Learning Environment Solutions, Inc.
4 Bartlett St ~ Marblehead  Massachusetts ~ 01945-2720
781.277.1151 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message