Does accessible => true in nested models cause crashes?

[JezC]

Hi, I've an app where there is a logical nesting of models. Think of
something like a web page:

organisation has_many websites has_many web_pages has_many :sections

The other end of each has_many is a "belongs_to".

When I put :accessible => true, :dependent => :destroy on the models
in this chain, trying to create an organisation fails. The server
crashes with messages like:

Rendered controller: organisations; dryml-tag: index-page (341.0ms)
Completed 200 OK in 1078ms (Views: 1061.0ms | ActiveRecord: 12.5ms)
Illegal instruction: 4

If I remove, all down the tree, ":accessible => true" in each
has_many, then I can create an organisation. If I leave the lower
levels with ":accessible => true", but remove it in the
"has_many :websites" association, then I can create an organisation.
If I keep the "accessible => true" in the organisation model, and
remove it in the website model for the pages association, then I can
again create an organisation:

organisation has_many !(accessible) websites has_many (accessible)
pages => OK
organisation has_many (accessible) websites has_many !(accessible)
pages => OK
organisation has_many (accessible) websites has_many (accessible)
pages => FAIL

How can I allow nested models to work on the next layer down, and
avoid this crash? I'm assuming that nesting models like this is
allowed in Hobo. I can't currently think how I'd organise my data if
I'm only allowed one level of nesting!

Should I be using "has_many :through" and ":accessible => true"? Does
that make deeply nested models work in Hobo?

I have an example app showing the failure mode that I can share on
GitHub if needed. Environment is rvm 1.10.1, Ruby 1.9.2p290, Rails
3.0.11, Hobo 1.3 on Mac OS 10.7.2

Apologies for yet another newbie distressed question. I am trying to
learn, honest!

[Bob Sleys]

I don't know what the problem is but I can see it's possible to have many levels of nested models with , :dependent => :destroy, , :accessible => true.  I have a fairly complex setup myself going 7 levels deep with one many-to-many mixed in and a few other wrinkles I it's all working fine.  Not that I didn't have my own share of bumps and cry's for help along the way.

Perhaps you could try to isolate the error down to a couple of simple models that demonstrates the problem and post them here.

Bob

[JezC]

Nested Accessible Model App that crashes for me...
https://github.com/JezC/Hobo-Nested-Accessible-Models

Not sure what to post here to make it easier than a "pull me now"
git :)

Thanks, JeremyC.

[JezC]

Ah ha. It's webrick. As a result of trying to debug a different
problem, I switched to unicorn as the web server. The problem went
away. Tried it on this problem, and webrick crashes, while unicorn
runs.

So, newbie tutorial suggestion? Change the Gemfile and server start
instructions to use 'unicorn'.

In the Gemfile, add the line:

gem 'unicorn', :group => :development

run 'bundle install'

then instead of 'rails s', run 'unicorn', which defaults to
127.0.0.1:8080 in a development environment.

Now off to see if this fixes some of the other problems I've run into.

Thanks for all the pointers!

On Jan 17, 5:26 pm, JezC <jezchatfi...@gmail.com> wrote:
> Nested Accessible Model App that crashes for me...https://github.com/JezC/Hobo-Nested-Accessible-Models

[Bryan Larsen]

I pulled your code to look into this. We shouldn't be having crashes
on webrick. However, you say it crashes when you add an
organization, but there is no organization model! Could you update
your repository so I can look again?

thanks,
Bryan

> --
> You received this message because you are subscribed to the Google Groups "Hobo Users" group.
> To post to this group, send email to hobo...@googlegroups.com.
> To unsubscribe from this group, send email to hobousers+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
>

[JezC]

Done. Checked using the Github UI - models are present.

Re-checked crash using webrick and success using unicorn. Have not
tried any other servers.

Dead easy to reproduce, probably:

bundle install
rails s

Then create an account, navigate to "Organisation" and "Create New
Organisation". End of server.

Cheers, JeremyC.

[Bryan Larsen]

On Thu, Jan 19, 2012 at 6:17 PM, JezC <jezcha...@gmail.com> wrote:
> Done. Checked using the Github UI - models are present.
>
> Re-checked crash using webrick and success using unicorn. Have not
> tried any other servers.
>
> Dead easy to reproduce, probably:
>
> bundle install
> rails s
>
> Then create an account, navigate to "Organisation" and "Create New
> Organisation". End of server.

All I can say is "it works for me". Can somebody else try it?

thanks,
Bryan

[JezC]

Thanks for trying. It is completely consistent for me, in a number of
different apps I've written. I've tested on a couple of different Macs
I have (Intel Core 2 Duo).

Might be dependent on Ruby version, compiler or OS dependency?

ruby 1.9.2 p290 (1.9.2p290 (2011-07-09 revision 32553) [x86_64-
darwin11.2.0])
C compiler is gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based
on Apple Inc. build 5658) (LLVM build 2335.15.00)
OS is Mac 10.7.2

Cheers, JeremyC

On Jan 28, 7:52 pm, Bryan Larsen <br...@larsen.st> wrote:

[Matt Jones]

On Jan 28, 2012, at 1:52 PM, Bryan Larsen wrote:

> On Thu, Jan 19, 2012 at 6:17 PM, JezC <jezcha...@gmail.com> wrote:
>> Done. Checked using the Github UI - models are present.
>>
>> Re-checked crash using webrick and success using unicorn. Have not
>> tried any other servers.
>>
>> Dead easy to reproduce, probably:
>>
>> bundle install
>> rails s
>>
>> Then create an account, navigate to "Organisation" and "Create New
>> Organisation". End of server.
>
> All I can say is "it works for me". Can somebody else try it?

I'm inclined to suspect webrick - we had a Rails 3.1 project that would randomly segfault during GC midway through the second request to hit Webrick. Switching off GC made *that* problem go away (at the expense of making the process gigantic) and switching to Unicorn made the segfaults disappear entirely.

--Matt Jones