On Mar 25, 2008, at 23:05 , Sho Fukamachi wrote:
Thanks for the responses Chris and Jan.
That's pretty much exactly what I thought - I just wanted to clear
it up!
The reason I asked was because I've seen what I consider to be some
not-very-good practise in some interface programs for Couch. For
example, in ActiveCouch, databases are treated basically like tables
- it seems to imply one should create a database called "people",
for example, and then another one called "blogs". This seemed to me
to be a pretty bad idea - trying to force CouchDB into a very RDBMS-
shaped hole, so I was wondering if they knew something I didn't
about the present or future scope of "map" - evidently not. I am not
sure how prevalent this kind of thinking is but evidently it needs
to be discouraged.
Ouch. It certainly does. ActiveCouch should reconsider
and use views instead of databases. One of the key features
of CouchDB is the schemaless storage of messy data in one
database and make sense of it via views.
[...]
With the possibility of using other languages for the M/R functions,
you could, for example, use Python to run the functions and from
within the functions use an HTTP request to get data from another
DB. If you really wanted that. I'd guess though that you'd be better
off with using a database merge with replication or implementing
things on the application level. I might be wrong, though :)
Ha, that sounds like a nightmare! I don't think anyone should be
thinking about that kind of thing except as a last resort.
Yeah, it'd be hard to guarantee the referential transparency
that map functions require. Anyway.
I guess the scenario I thought could be possible was that design
docs could be definable at the root level of the server, above the
databases, and then look into all docs in all databases. It's no
surprise, though, that this isn't done - there would be no advantage
beyond a superficially more pleasant namespace.
With the new architecture that separates views from storage
this might even be possible. Damien? It might be useful for
administrative tasks.
Has the community arrived at a kind of "best practise" for
differentiating between record types? In the wiki using the key
"type" is suggested, I am wondering how official this is. Not that
it needs to be official, of course, but establishing some sort of
convention is probably a good idea to get everyone on the same page.
We started using "type" or "Type" sort of as a convention because
we wanted to encourage a de-facto standard for programming
CouchDB. This worked well so far and we couldn't find any
problems. But I guess not much thinking went into it, so we
still might regret that at some point. So, if you (anyone) can
think of problems (and present a better solution), please
speak up.
If it is, what might be nice would be to promote "type" in a doc to
a reserved magic word like _id or _rev. A built-in function to get
"all documents by type" and/or present a list of filterable types in
the web interface would perhaps help make the database more
approachable to RDBMS refugees and help encourage people towards
understanding document-based data structures, and away from the
table-based mentality. Just a thought.
I had that exact idea too, but dismissed it. This is not
inherent to CouchDB and thus shouldn't be part of
the API. As far as documenting things goes, if we all
use "type" or "Type" in our examples, people will pick
this up just as well.
Cheers
Jan
--
