In regards to naming of design documents

[Chris Stockton <ch...@gmail.com>]

Hello,

We are deciding our convention for how we will emulate tables in couch
db. Our current idea is the user named tables will each have a design
document with punycode names. "tableňame" is a design doc stored as ->
I.E. _design/tableame-uqb. Of course this brings up a collision
problem for our system defined design docs, such as lucene etc. So it
was decided system design docs would begin with _ and user tables
would be prohibited from beginning with _. However this gives a uneasy
feeling as _ is very much reserved as a first character in both
properties and database names, although as of .10 _design/_foo is
allowed, I would like to make sure this is considered acceptable
practice and will remain available moving forward.

Some thoughts have been a design document specifying the tables within
the database, like _design/tables, this seems like a fairly clean
approach and I am unsure any advantage is given by having separate
design docs for each table as they contain no views (currently those
live in a separate design doc) just meta data about the table. I would
appreciate hearing any solutions people have made to this problem
(user created tables in a database).

-Chris

Re: In regards to naming of design documents

[Nathan Stott <nr...@gmail.com>]

I don't have an answer to your question; however, I have a question.  Why
are you using couchdb to try to simulate tables?  Why not just use a RDBMS?

On Tue, Nov 10, 2009 at 6:06 PM, Chris Stockton
<ch...@gmail.com>wrote:

> Hello,
>
> We are deciding our convention for how we will emulate tables in couch
> db. Our current idea is the user named tables will each have a design
> document with punycode names. "tableňame" is a design doc stored as ->
> I.E. _design/tableame-uqb. Of course this brings up a collision
> problem for our system defined design docs, such as lucene etc. So it
> was decided system design docs would begin with _ and user tables
> would be prohibited from beginning with _. However this gives a uneasy
> feeling as _ is very much reserved as a first character in both
> properties and database names, although as of .10 _design/_foo is
> allowed, I would like to make sure this is considered acceptable
> practice and will remain available moving forward.
>
> Some thoughts have been a design document specifying the tables within
> the database, like _design/tables, this seems like a fairly clean
> approach and I am unsure any advantage is given by having separate
> design docs for each table as they contain no views (currently those
> live in a separate design doc) just meta data about the table. I would
> appreciate hearing any solutions people have made to this problem
> (user created tables in a database).
>
> -Chris
>

Re: In regards to naming of design documents

[Brian Candler <B....@pobox.com>]

On Thu, Nov 12, 2009 at 01:35:46PM -0700, Chris Stockton wrote:
> > Remember you don't *have* to have separate design docs per table - you can
> > have multiple views within the same design doc, and the user doc will only
> > be serialized once to the view server to build all those views.
> Part of the design (which I left out in the previous mail) is we will
> be dynamically creating views fairly often, placing them into the
> tables design document. I would like to have a single design document
> with all views for a database, as well as the lookup for the tables.
> However from my understanding when we added/updated views for a design
> doc, it would cause the other views under that design document to also
> re-index. I could see on a large database with 100+ tables, having to
> re-index every view for all tables for a single view update could get
> expensive. I would appreciate you to kindly correct me if I am wrong
> as that would perhaps sway our design decisions.

That's correct. On the flip side though: every document is sent once to the
view server for each design document. So if you have 100 design docs then
insert a load of user documents, then each new user document will be
serialised and sent to the view server 100 times, only to be discarded by
the majority of the views.

There are some patches floating around which allow you to do some
pre-filtering on the couchdb side to limit which documents are sent to each
design document's views based on some attribute of the document.

Re: In regards to naming of design documents

[Paul Davis <pa...@gmail.com>]

On Thu, Nov 12, 2009 at 3:57 PM, Chris Stockton
<ch...@gmail.com> wrote:
> Hello,
>
> Thank you for the response,
>
> On Thu, Nov 12, 2009 at 1:41 PM, Paul Davis <pa...@gmail.com> wrote:
>> You're spot on here. If you add a view to a design document, all views
>> in that design document will be invalidated and re-indexed.
>
> Thank you for confirming this, seems clear benefits exist for mapping
> "tables" to design docs, my final question remaining is this going to
> be allowed in future versions: "_design/_foo"?
>

Chris,

I am uncertain. I would lean towards not, but you should submit that
to the dev@ mailing list so we can get some consensus.

Paul Davis

Re: In regards to naming of design documents

[Chris Stockton <ch...@gmail.com>]

Hello,

Thank you for the response,

On Thu, Nov 12, 2009 at 1:41 PM, Paul Davis <pa...@gmail.com> wrote:
> You're spot on here. If you add a view to a design document, all views
> in that design document will be invalidated and re-indexed.

Thank you for confirming this, seems clear benefits exist for mapping
"tables" to design docs, my final question remaining is this going to
be allowed in future versions: "_design/_foo"?

Re: In regards to naming of design documents

[Paul Davis <pa...@gmail.com>]

>> Remember you don't *have* to have separate design docs per table - you can
>> have multiple views within the same design doc, and the user doc will only
>> be serialized once to the view server to build all those views.
> Part of the design (which I left out in the previous mail) is we will
> be dynamically creating views fairly often, placing them into the
> tables design document. I would like to have a single design document
> with all views for a database, as well as the lookup for the tables.
> However from my understanding when we added/updated views for a design
> doc, it would cause the other views under that design document to also
> re-index. I could see on a large database with 100+ tables, having to
> re-index every view for all tables for a single view update could get
> expensive. I would appreciate you to kindly correct me if I am wrong
> as that would perhaps sway our design decisions.

Chris,

You're spot on here. If you add a view to a design document, all views
in that design document will be invalidated and re-indexed.

HTH,
Paul Davis

Re: In regards to naming of design documents

[Chris Stockton <ch...@gmail.com>]

Hello,

Thank you for your responses,

On Tue, Nov 10, 2009 at 5:57 PM, Nathan Stott <nr...@gmail.com> wrote:
> I don't have an answer to your question; however, I have a question.  Why
> are you using couchdb to try to simulate tables?  Why not just use a RDBMS?
Our decisions to use couch took into account it's lack of constraints
seen in a RDBMS, which is why for 90% of our purpose it fits so well
into our design. I would be happy to explain the reasoning behind the
design decisions for some of the problems we are solving, and why
couch is the solution offline if you would like.

On Wed, Nov 11, 2009 at 1:18 AM, Brian Candler <B....@pobox.com> wrote:
> Possible solution: if your emulation layer is called "tablefoo", then have
> _design/tablefoo_<tablename> or _design/tfuser_<tablename>
We were thinking of doing something like this, might be a best-approach.

> Remember you don't *have* to have separate design docs per table - you can
> have multiple views within the same design doc, and the user doc will only
> be serialized once to the view server to build all those views.
Part of the design (which I left out in the previous mail) is we will
be dynamically creating views fairly often, placing them into the
tables design document. I would like to have a single design document
with all views for a database, as well as the lookup for the tables.
However from my understanding when we added/updated views for a design
doc, it would cause the other views under that design document to also
re-index. I could see on a large database with 100+ tables, having to
re-index every view for all tables for a single view update could get
expensive. I would appreciate you to kindly correct me if I am wrong
as that would perhaps sway our design decisions.

Regards,

-Chris

Re: In regards to naming of design documents

[Brian Candler <B....@pobox.com>]

On Tue, Nov 10, 2009 at 05:06:14PM -0700, Chris Stockton wrote:
> We are deciding our convention for how we will emulate tables in couch
> db. Our current idea is the user named tables will each have a design
> document with punycode names. "tableňame" is a design doc stored as ->
> I.E. _design/tableame-uqb. Of course this brings up a collision
> problem for our system defined design docs, such as lucene etc.

Possible solution: if your emulation layer is called "tablefoo", then have
_design/tablefoo_<tablename> or _design/tfuser_<tablename> 

Remember you don't *have* to have separate design docs per table - you can
have multiple views within the same design doc, and the user doc will only
be serialized once to the view server to build all those views.