Storing design documents on the filesystem?
Jonathan Lange
I came across a document describing how to store design documents and
views on the filesystem at:
http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/DesignDocsFilesystem
It sounds really interesting to me, but there are gaps in the documentation.
In particular:
* it isn't clear that you need to restart couchdb in order for this
to take effect
* it isn't clear _how_ to restart a couchdb started by desktopcouch
(there's got to be a pidfile somewhere!)
* if you've already created a database by mucking around according
to one of the other docs, it's not clear how to switch to this kind of
layout
* when I follow the instructions, the database is created, but
there's no design doc, despite the existence of js files.
I'll be happy to patch the documentation, once I know the answers :)
Thanks,
jml
Jonathan Lange
...
> * when I follow the instructions, the database is created, but
> there's no design doc, despite the existence of js files.
>
This one has been answered. I had forgot to include the 'databases'
path segment. The other questions still stand.
I also discovered the 'update_design_documents' function in
'start_local_couchdb'. Maybe it would be useful to be able to run this
from a standalone script, without restarting the db?
jml
Stuart Langridge
Part of the reason that this is fairly lightly documented is that
no-one's using it yet, so I am not totally sure that it works perfectly.
If you use it you'll be the first person to do so seriously (although
the second I've spoken to about it in the last 24 hours; weird, eh?).
Agreed that it isn't clear from the docs that you have to restart
desktopcouch, and it should be. Restarting DC is currently more awkward
than it ought to be; see the Troubleshooting doc for the "oh no it's all
gone wrong" procedure. There is a desktopcouch-stop script, but it
doesn't work properly, and it needs to. Being able to run
start_local_couchdb.update_design_docs independently would possibly help
with this (I mean, you could always just do python -c "import
desktopcouch.start_local_couchdb;
desktopcouch.start_local_couchdb.update_design_docs()", I suppose :))
I've also just been informed of the existence of
couchdb.design.ViewDefinition.sync_many which will do a better job of
syncing the view definitions than the current "just overwrite them"
approach, heh.
Patches (to documentation or DC itself) welcome...?
sil
Jonathan Lange
<stuart.l...@canonical.com> wrote:
> On 01/02/2010 03:27 AM, Jonathan Lange wrote:
>> I came across a document describing how to store design documents and
>> views on the filesystem at:
>> http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/DesignDocsFilesystem
>>
>> It sounds really interesting to me, but there are gaps in the documentation.
>>
>> In particular:
>> * it isn't clear that you need to restart couchdb in order for this
>> to take effect
>> * it isn't clear _how_ to restart a couchdb started by desktopcouch
>> (there's got to be a pidfile somewhere!)
>> * if you've already created a database by mucking around according
>> to one of the other docs, it's not clear how to switch to this kind of
>> layout
>> * when I follow the instructions, the database is created, but
>> there's no design doc, despite the existence of js files.
>>
>> I'll be happy to patch the documentation, once I know the answers :)
>
> Part of the reason that this is fairly lightly documented is that
> no-one's using it yet, so I am not totally sure that it works perfectly.
> If you use it you'll be the first person to do so seriously (although
> the second I've spoken to about it in the last 24 hours; weird, eh?).
> Agreed that it isn't clear from the docs that you have to restart
> desktopcouch, and it should be.
OK. I've updated the wiki page at:
http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/DesignDocsFilesystem
> Restarting DC is currently more awkward
> than it ought to be; see the Troubleshooting doc for the "oh no it's all
> gone wrong" procedure. There is a desktopcouch-stop script, but it
> doesn't work properly, and it needs to.
Are there bugs filed about this? Are there any thoughts on how it should work?
> Being able to run
> start_local_couchdb.update_design_docs independently would possibly help
> with this (I mean, you could always just do python -c "import
> desktopcouch.start_local_couchdb;
> desktopcouch.start_local_couchdb.update_design_docs()", I suppose :))
>
I'm really, really lazy though.
> I've also just been informed of the existence of
> couchdb.design.ViewDefinition.sync_many which will do a better job of
> syncing the view definitions than the current "just overwrite them"
> approach, heh.
>
Hmm. Thanks, I'll look into it.
Right now, I've got a _design directory in my Bazaar tree symlinked
under the appropriate xdg directories. I'm also very, very close to a
testresources[1] set up that will install view files appropriately so
I don't have to do any fiddling as a part of my TDD cycle.
I'm unsure how to handle changes to views and the design document
after the release of the application -- but I'm sure I can cross this
hurdle when I'm ready to release :)
> Patches (to documentation or DC itself) welcome...?
>
I'm tempted. I've already done a fair bit of yak shaving with
testtools & testresources.
jml
Stuart Langridge
>> Restarting DC is currently more awkward
>> than it ought to be; see the Troubleshooting doc for the "oh no it's all
>> gone wrong" procedure. There is a desktopcouch-stop script, but it
>> doesn't work properly, and it needs to.
>
> Are there bugs filed about this? Are there any thoughts on how it should work?
Thoughts, yes. Bugs, no. Essentially, the desktopcouch-stop script
should work; one of the use-cases, as mentioned, is that a new package
is installed (as root), which installs new design docs, and that package
restarts all running desktopcouches in its postinst (thus causing the
new design docs to be read).
> Right now, I've got a _design directory in my Bazaar tree symlinked
> under the appropriate xdg directories. I'm also very, very close to a
> testresources[1] set up that will install view files appropriately so
> I don't have to do any fiddling as a part of my TDD cycle.
See the existing desktopcouch tests; they set up a temporary "xdg"
environment in /tmp, and you'd probably want to do something similar for
your tests.
> I'm unsure how to handle changes to views and the design document
> after the release of the application -- but I'm sure I can cross this
> hurdle when I'm ready to release :)
See above point about the postinst :)
sil
Jonathan Lange
<stuart.l...@canonical.com> wrote:
> On 01/03/2010 02:49 AM, Jonathan Lange wrote:
>> Right now, I've got a _design directory in my Bazaar tree symlinked
>> under the appropriate xdg directories. I'm also very, very close to a
>> testresources[1] set up that will install view files appropriately so
>> I don't have to do any fiddling as a part of my TDD cycle.
>
> See the existing desktopcouch tests; they set up a temporary "xdg"
> environment in /tmp, and you'd probably want to do something similar for
> your tests.
>
Right. I copied heavily from the existing couch tests, but used
testresources to make it less global.
It's still mostly crap, but you can look at lp:~jml/+junk/lister
(lister/model.py, lister/tests/test_model.py and
lister/tests/helpers.py being the relevant files) if you'd like to see
more.
jml