#26 ✓resolved

views failing in trunk

Reported by hkstar | November 23rd, 2008 @ 04:25 PM

Hi there yet again,

Views are failing in the current build of trunk. They can be accessed once, but when the model is loaded again, they fail. It's not caught by the specs since they only load the model once.

For a demonstration, save the following file somewhere and run it twice. The first time will succeed and output 0,0. The second time you will see an exception:

/Library/Ruby/Gems/1.8/gems/couchrest-0.10.1/lib/couchrest/core/design.rb:84:in fetch_view': undefined methodview' for nil:NilClass (NoMethodError)

The example is the Articles class straight out of specs: http://friendpaste.com/sZ4AxdWn

Bug? Or is this just my screwed up system? Wouldn't be the first time, heh.

Thanks a lot as usual...


Comments and changes to this ticket

  • Ray Morgan

    Ray Morgan December 17th, 2008 @ 12:36 PM

    I can confirm that this is happening. I will (hopefully have time to) write up a spec for it when I get home tonight.

  • Nolan Darilek

    Nolan Darilek December 18th, 2008 @ 12:16 PM

    I can not only confirm this, but I've seen a slightly different variation. I wonder if it isn't just happening the second time the same view is accessed, but the second time any view is accessed?

    I have an import script that imports two CouchRest::Models with custom model views in the same run. The importer first imports a batch of node objects, then imports ways, all in the same run. The node documents and their associated view load fine. Ways don't load at all, though, and their view fails to be added. I don't know if the triggering behavior is two views on two separate models in the same database or what.

  • Max Aller

    Max Aller December 28th, 2008 @ 10:26 PM

    I'd also like to second this bug. I think I've narrowed it down a tad bit more, though. At least in my testing, if I have "cast :blah, :as => 'OtherBlah'" in my model, it fails on the second time of loading. But if I don't, then the views generate fine (I think).

  • Max Aller

    Max Aller December 29th, 2008 @ 09:24 PM

    K, my previous comment was wrong.

    Anyway, after about...3 hours, I've narrowed down one possible solution. See attached.

    Also I wish git made patches from the branch name, not the commit comment :P

  • Nolan Darilek

    Nolan Darilek December 31st, 2008 @ 09:14 AM

    Unfortunately, this patch doesn't resolve the problem for me. See here for my use, though be aware that I'm using my own branch with compaction support and my attempt at an automatic/manually-triggered bulk save system, so if you actually expect it to work then you'll need that branch. :)

    This code imports data that is saved with nodes first, then ways. The nodes and their associated view_by:external_id are created correctly. Ways, on the other hand, aren't created the same--that is, their view_by:external_id view doesn't seem to save, even though it is created exactly the same in Ruby. It's as if view creation succeeds once and only once, then fails the second time.

    Hopefully this gets resolved soon. I'm trying to track it down as well but am not having as much luck as I'd like.

  • Max Aller

    Max Aller December 31st, 2008 @ 09:57 AM

    To state the psuedo-obvious, I think what's happening is if the design doc isn't getting initialized correctly if it's not being created right there (within that server bootup, I mean). Not sure why, though. Setting the database= property on the design doc helped a little, but ended up producing a different error iirc. I'll take a look at your code tonight.

  • Joe Martinez

    Joe Martinez January 13th, 2009 @ 02:21 PM

    +1 for Max's patch. Fixed my problem.

  • hkstar

    hkstar January 13th, 2009 @ 05:22 PM

    +1 for Max's patch, works for me too. Thanks Max!

  • J. Chris A.

    J. Chris A. January 19th, 2009 @ 02:50 PM

    • State changed from “new” to “resolved”

    I applied this patch (although without reproducing the bug). I'll close this ticket, but please reopen if this patch doesn't fix it.

  • Nolan Darilek

    Nolan Darilek January 22nd, 2009 @ 09:48 AM

    No, unfortunately this isn't working for me. It may be that view creation isn't interacting well with the bulk_save changes I introduced, which is what I'm using as it drastically speeds up imports and storage space requirements. Here is the error I get:

    /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:208:in process_result': HTTP status code 412 (RestClient::RequestFailed)

    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:178:in `transmit'
    from /usr/lib/ruby/1.8/net/http.rb:543:in `start'
    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:175:in `transmit'
    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:114:in `execute_inner'
    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:106:in `execute'
    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:93:in `execute'
    from /var/lib/gems/1.8/gems/rest-client-0.8.2/lib/rest_client.rb:53:in `post'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest.rb:113:in `post'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/database.rb:163:in `bulk_save'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/database.rb:127:in `save'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/document.rb:41:in `save'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/design.rb:55:in `save'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/model.rb:452:in `refresh_design_doc'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/model.rb:347:in `view'
    from /var/lib/gems/1.8/gems/couchrest-0.12.4/lib/couchrest/core/model.rb:332:in `method_missing'
    from ./bin/../lib/lazy_planet/importer/callbacks.rb:20:in `way'
    from /var/lib/gems/1.8/gems/osmlib-base-0.1.3/lib/OSM/StreamParser.rb:152:in `_end_way'
    from /var/lib/gems/1.8/gems/osmlib-base-0.1.3/lib/OSM/StreamParser.rb:116:in `on_end_element'
    from /var/lib/gems/1.8/gems/osmlib-base-0.1.3/lib/OSM/StreamParser/Expat.rb:42:in `parse'
    from /var/lib/gems/1.8/gems/osmlib-base-0.1.3/lib/OSM/StreamParser/Expat.rb:39:in `parse'
    from ./bin/../lib/lazy_planet/importer/base.rb:14:in `start'
    from bin/lp_import:18

    Here's how to duplicate:

    1. Check out my project from git://github.com/thewordnerd/lazy_planet.
    2. Install the osmlib-base and xmlparser gems. There may be another gem or two needing installed, I haven't packaged this nicely yet. You can eliminate the xmlparser dependency by commenting out the ENV setting in lib/lazy_planet/importer.rb. 3 Download the dataset which I'll hopefully be able to attach as Brazos.osm.
    3. Run bin/lp_import localhost:5984/osm path/to/Brazos.osm.
    4. You should get the error in a few minutes. This happens when the first way is imported, which is the second view the app tries to create.

    Not sure if this is the same issue, but it seems to be related.

  • Nolan Darilek

    Nolan Darilek January 24th, 2009 @ 10:07 AM

    OK, this looks like a slightly different issue, so I think this one can stay closed. Please pull from my fork:


    The reason my view wasn't being created was that, when Database.save is called for a standard save and there are docs cached for bulk-saving, the bulk save is performed first. I changed the code to perform the individual document save first, then the bulk, so the view is created even if the bulk save fails. This doesn't solve my issue, but it at least ensures the view is created even if another save fails.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

"CouchDB, close to the metal." <a href="http://github.com/jchris/couchrest/tree/master">CouchRest</a> is a RESTful layer for accessing CouchDB, based off CouchDB's included Javascript reference client. CouchRest also includes helpers for running large queries etc. There is also a base class for ActiveRecord / Datamapper style ORM, called CouchRest::Model.