> Would the ideal solution to this be to make capture work with nested
> calls?
I'm not sure what approach you'd use to make that work, as the capture
helper at present already does some 'funky' stuff. However if you can
make it work, I can't see the harm in such a patch being applied.
--
Chee
On 8/8/07, paccator <[EMAIL PROTECTED]> wrote:
>
> Why has_many doesn't set target for objects in its collection?
>
> E.g. when
>
> class Author < ActiveRecord; has_many :posts; end
> class Post < ActiveRecord; belongs_to :author; end
>
> then
>
> some_author.posts.each {|p| puts p.author.na
Ahoy!
I've got two patches in Trac that fix cases where the finder for a has_many
association works with :include but it's count() fails.
http://dev.rubyonrails.org/ticket/9167
http://dev.rubyonrails.org/ticket/9175
Both are small, well-tested and fix existing features without adding new
ones.
On 8/7/07, Trevor Squires <[EMAIL PROTECTED]> wrote:
>
> Hey,
>
> 2 comments from me:
>
> 1 - using :include one-level-deep when you are fetching *one*
> toplevel object *and* you are not issuing :conditions on
> the :included tables is *always* (well, I've never found an
> exception) slower.
>
>
Hey,
2 comments from me:
1 - using :include one-level-deep when you are fetching *one*
toplevel object *and* you are not issuing :conditions on
the :included tables is *always* (well, I've never found an
exception) slower.
x = Foo.find(4678. :include => [:incoming_messages, :outgoing_mess
On 8/7/07, Frederick Cheung <[EMAIL PROTECTED]> wrote:
> Executive Summary:
>
>
> I've recently come across some performances problems with eager
> loading multiple has_many relationships (and to a lesser extent a
> single has_many with many objects in the collection) and had some
Executive Summary:
I've recently come across some performances problems with eager
loading multiple has_many relationships (and to a lesser extent a
single has_many with many objects in the collection) and had some
thoughts.
The case I came across involved some models lik
It appears that the new partial layouts don't work in conjunction
with content_tag_for. The call to render with :template doesn't
return anything if the template uses content_tag_for.
See this blog post for how I'm trying to use them:
http://opensoul.org/2007/8/3/edge-rails-gets-layouts-for-p
> That said, :include is not a solution, cause it also unnecessarily
> makes bigger query just to fetch object which I already have in
> memory.
> Instant variable is not enough. My example was intentionally simple
> just to show what I mean.
> Imagine that I have few authors somewhere, and I coll
Yikes. Ok, noted. We've had better success before of getting data
and participation from "prediction markets" than just sending out
opinion emails before or discussion lists. Since it's free, and I
love Rails, and I'm not selling viagra thought I could contribute
something fun for the core grou
I agree with Josh. Additionally, why would you repeat the same
question if it was already discussed in the past.
On 8/7/07, inkling <[EMAIL PROTECTED]> wrote:
>
> Sorry if we a difference of opinion, but I think its very relevant
> information to get from the core group if there is some kind of
>
Sorry if we a difference of opinion, but I think its very relevant
information to get from the core group if there is some kind of
consensus from them on a Rails 2.0 release. I know a bit where Koz
thinks this is going to land, but not others.
Also from example, this is has been a type of questi
> I know there have been discussions here about a date for this, and I
> know 1.2.4 is coming before Rails 2.0 is. And I know everyone is
> working their butts off, so this isn't trying to antagonize at all,
> just thought it might be fun to see what the market says when Rails
> 2.0 is coming.
I know there have been discussions here about a date for this, and I
know 1.2.4 is coming before Rails 2.0 is. And I know everyone is
working their butts off, so this isn't trying to antagonize at all,
just thought it might be fun to see what the market says when Rails
2.0 is coming.
http://home
Sorry, but I thought it is about Rails implementation details,
has_many implementation details.
On Aug 7, 3:01 pm, Manfred Stienstra <[EMAIL PROTECTED]> wrote:
> This mailing list is meant for discussion about implementation
> details of Rails only. You can post support requests to Rails Talk
This mailing list is meant for discussion about implementation
details of Rails only. You can post support requests to Rails Talk
[1] or #rubyonrails on freenode.
[1] http://groups.google.com/group/rubyonrails-talk
On Aug 7, 2007, at 2:44, paccator wrote:
>
> Why has_many doesn't set targe
Wait a min..
some_author.posts.each {|p| puts p.author.name}
p.author.name == some_author.name !
On 8/7/07, paccator <[EMAIL PROTECTED]> wrote:
>
> Why has_many doesn't set target for objects in its collection?
>
> E.g. when
>
> class Author < ActiveRecord; has_many :posts; end
> class Post
Why has_many doesn't set target for objects in its collection?
E.g. when
class Author < ActiveRecord; has_many :posts; end
class Post < ActiveRecord; belongs_to :author; end
then
some_author.posts.each {|p| puts p.author.name}
will require additional queries to fetch author for each pos
Nice work, applied !
On 8/7/07, Aleksey Kondratenko <[EMAIL PROTECTED]> wrote:
>
> After http://dev.rubyonrails.org/ticket/8889 got applied :select on
> habtm association is ignored.
> The fix is both tiny and straightforward.
>
> Ticket URI is: http://dev.rubyonrails.org/ticket/9207
>
> Regards,
After http://dev.rubyonrails.org/ticket/8889 got applied :select on
habtm association is ignored.
The fix is both tiny and straightforward.
Ticket URI is: http://dev.rubyonrails.org/ticket/9207
Regards, Aleksey Kondratenko.
--~--~-~--~~~---~--~~
You received th
20 matches
Mail list logo
