Callbacks on large number of EmbeddedDocuments blows stack

[Jamie Orchard-Hays]

I wonder if anyone else has encountered this. I've written a detailed description in a bug ticket at github.

https://github.com/jnunemaker/mongomapper/issues/405

(Not a problem on Rails 2.3.x and MM 0.8.6.)

I'm hoping to have time to dig into the MM code to see if I can offer up a fix soon.

Jamie

[Brandon Keepers]

Jamie,

That is the same issue as https://github.com/jnunemaker/mongomapper/issues/265. A lot of people have experienced the issue, but nobody has submitted a fix for it.

I've never run into it because I don't use embedded docs in that manner. If I ever sense that an embedded association could end up with more than two or three documents, I pull it out into a collection. I've never had an instance where I would need every associated doc whenever I fetched the parent. I'm not saying there's not a legitimate use case for needing ~80 embedded docs every time the parent is fetched, but I do think it's rare and most people would be better off using a non-embedded document.

Unless someone can figure out a way to hack ActiveSupport 3's Callbacks, then I agree with @jnunemaker, I think we should just pull callbacks on embedded documents.

=b

--

You received this message because you are subscribed to the Google

Groups "MongoMapper" group.

For more options, visit this group at

http://groups.google.com/group/mongomapper?hl=en?hl=en

[Jamie Orchard-Hays]

Thanks, Brandon. My use case is I'm storing monthly reports. It makes a lot of sense to me to store my data this way. I'd love to hear arguments against it. My experience that past two years working extensively is that there is a sweet spot I have to find for certain situations between write and read performance when I have large trees like for these reports.

I'll take bug-specific comments to the ticket.

Cheers,

Jamie