http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10674 2008/12/2 acechase <acechase< at >gmail.com> Ah-ha! Now I understand why my little un-announced plugin suddenly got some watchers on github ;) So, here seems like as good a place as any to thrash it out. What do we think I/we'd need to do to get it into core? As someone pointed out, it's pretty incomplete so I'm sure I've not covered all the edge cases, although I think it does a pretty good job of giving up if it can't find something that it thinks is the right inverse / reciprocal relationship (and we're using it in a production app here and it's yet to fall over). The first natural extension to me would be to allow for :inverse options on association definitions that would allow for getting round trying to work it out, e.g. something like: class FlamingStick < ActiveRecord::Base belongs_to :extreme_juggler, :inverse => :flaming_sticks end class ExtremeJuggler < ActiveRecord::Base has_many :flaming_sticks, :inverse => :extreme_juggler end Although, for these simple cases it does seem like extra wo Murray Steele 2008-12-03T15:59:49 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10673 Mislav Marohnić wrote: Spawner *is a monitoring superb daemon*, as long as you start Mongrels as described in: http://capify.org/getting-started/from-the-beginning instead of relying on mongrel_rails. Dee Zsombor 2008-12-03T15:55:02 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10672 Sorry, this was problem in our programmers in other department, we solve this problem. Thanx you for help. On Dec 3, 6:13 pm, "Mislav Marohnić" <mislav.maroh...< at >gmail.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Ivan Evtuhovich 2008-12-03T15:15:43 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10671 2008/12/3 Ivan Evtuhovich <evtuhovich< at >gmail.com> Well, you can contribute a failing test and a patch to Rails yourself. This wouldn't be the first time Rails fixed a badly implemented HTTP spec by Apple. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Mislav Marohnić 2008-12-03T15:13:54 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10670 I understand, but it is imposible to fix Apple library. Could you tell me, how to fix this inside the application, i do not want to 'monkey patching' rails code. On Dec 3, 5:47 pm, "Mislav Marohnić" <mislav.maroh...< at >gmail.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Ivan Evtuhovich 2008-12-03T14:59:54 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10669 And it should. The separator of headers and body is "\r\n\r\n". Anything else is wrong. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Mislav Marohnić 2008-12-03T14:47:42 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10668 Hello. iPhone use NSURLRequest, NSURLConnection to POST data to rails site. Request is the next: POST / HTTP/1.1 User-Agent: CFNetwork/330 Content-Type: multipart/form-data; boundary=------580a9a040b19fc6621c596d9c40097f7 Accept: */* Accept-Language: ru Accept-Encoding: gzip, deflate Content-Length: 295 Connection: keep-alive Host: 192.168.0.20:8888 --------580a9a040b19fc6621c596d9c40097f7 Content-Disposition: form-data; name="authenticity_token" 86a4347fae09e23cf592eed6eb324cd61f3b9e5f --------580a9a040b19fc6621c596d9c40097f7 Content-Disposition: form-data; name="picures[pic]" 111 --------580a9a040b19fc6621c596d9c40097f7-- There too mane \r\n after Host:192.168.0.20:8888, therefore rails return "Bad content body". Could somebody fix this? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, sen Ivan Evtuhovich 2008-12-03T14:40:23 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10667 I've been playing around with Dirty (change tracking) recently, and have a question about the field_changed? method: def field_changed?(attr, old, value) if column = column_for_attribute(attr) if column.type == :integer && column.null && (old.nil? || old == 0) # For nullable integer columns, NULL gets stored in database for blank (i.e. '') values. # Hence we don't record it as a change if the value changes from nil to ''. # If an old value of 0 is set to '' we want this to get changed to nil as otherwise it'll # be typecast back to 0 (''.to_i => 0) value = nil if value.blank? else value = column.type_cast(value) end end old != value end I understand the reasoning behind the if...else statement, but what about the situation where you're changing a nullable integer column from 0 to '0'? In this case it will go into the if block, leave 'value' unchanged, and end up returning true - this seems incorrect to me! If the Ben Symonds 2008-12-03T12:08:00 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10666 What Koz meant is that with Mongrels you always need a monitoring daemon in production (otherwise you'll be miserable). Because the monitoring software already knows how to start/stop/restart mongrels (because you've configured it), it's best practice to simply use that for managing Mongrels. We are using god in the company and now that these scripts are gone, we're switching to managing deployments through god because it kinda feels right. Also, the limitation of these scripts compared to, say, mongrel_cluster was that you couldn't specify unix user/group for processes. Also, Koz likes Passenger very much and Rails is opinionated, remember? ;) j/k To conclude, I have nothing against this change, I just wanted to be sure why it was done. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send em Mislav Marohnić 2008-12-02T21:46:46 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10665 I ran across a small bug in the preloading code for has_one :through - see http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1507 for more details. +1s and/or feedback for the patch (against 2-2-stable) appreciated. --Matt Jones al2o3cr< at >gmail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Matt Jones 2008-12-02T21:45:06 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10664 Michael Koziarski wrote: I could say the contrary, on every project with a solid Mongrel or FCGI based setup the spawner script was used. It requires no extra configuration unlike monit/god/runit. It also cares for safely exiting a process *after* the current request was processed unlike the defaults for monit/god/runit etc. The same can be said about reaper, it *always* works as long as you invoke it with a /full/path/to/current/process/reaper. In what way did you find them to be broken? Dee Zsombor 2008-12-02T21:28:28 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10663 I understand -- it would be a case where you do not want to deliberately cache the resultset, and so, it would not be quite like an association proxy. But of course, each is all that's needed for things like select/reject/inject. And inject, in particular, should be safe -- select/reject, any?, all?, and similar things will still benefit from not _holding_ all items in memory, even if all items will have to be iterated over anyway. In fact, it's my understanding that this is the main reason for having an enumerable interface -- when using such an interface, you're not required to know or care whether it's a native array, the result of slurping the entire table, one select call per iteration, or anything in between. Of course, there are also the things like sort, uniq, and map that would ruin your whole day -- though map, at least, could be implemented in a lazier way, for this purpose. On Tue, Dec 2, 2008 at 9:55 AM, acechase <acechase< at >gmail.com> wrote: --~--~---------~--~----~------------~-------~--~- David Masover 2008-12-02T21:15:39 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10662 On Dec 1, 12:14 pm, "Michael Koziarski" <mich...< at >koziarski.com> wrote: Three cheers to that! h-lame has done some really good work getting the parental_control plugin working, but I think it would make hammering out the trickier bits much easier if it was part of core. As it stands now, without something like parental_control, if you're using eager includes to avoid 1+N query problems, you have to write your code to only ever use associations through the direction in which they were loaded. Which, IMO, is one nasty leak of encapsulation in the ORM. -ac --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------ acechase 2008-12-02T16:14:55 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10661 On 2 Dec 2008, at 15:55, acechase wrote: I don't thing that's necessarily true. Consider for example (1..10000000).select {|x| x == 100000} This range contains ten million elements, but executing that statement doesn't require having all of those in memory at any given time (keep an eye on ruby's memory consumption while this runs) On the other hand this would (1..10000000).to_a.select {|x| x == 100000} Of course if the result set you are returning is large eg (1..10000000).to_a.select {|x| x % 2 == 0 } then that will take a big chunk of memory but that seems fair enough. Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~---- Frederick Cheung 2008-12-02T16:11:28 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10660 The one problem I see with this approach is that it does not allow for the eager-loading of polymorphic associations. In fact, as the code stands now I couldn't get vanilla :include options to work, only :joins (but I think that's just a little bug in the parsing of the options hash). The problem is, when Rails uses the eager include approach rather than the join approach it looks through the entire result set to see which associations need to be queried and then grabs those associations in separate queries. This is relatively efficient because the object graph is being built out for all objects at once, my guess is that doing the same thing one object at a time would be very difficult to do efficiently. As an alternative approach, the project I work on uses a home-grown version of what Andreas mentions as one of the two options -- we fetch IDs and process them in groups. The one thing I really like about that approach is all the same finder options still work as expected with no additional programming re acechase 2008-12-02T16:06:47 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10659 David, I don't think it would be possible to support the enumerable interface in this extension because it would negate the memory management benefits that are the reason for using such a technique. Looking at the code, it looks like Andreas instantiates one ruby object at a time from the result set, then yields that object to the block for work to be done on it and frees the object after the yield returns (it's a little fancier than this with the Oracle extension, but in the MySQL version that's about it). If you were to allow for things like select/ reject, inject, etc then you're back in a situation where some potentially large subset (or all) of those ruby objects are going to be held in memory. As for named scopes, like you said, I think that just works. The named scopes just insert there additional magic into the final query that gets made (adds additional conditions, joins, etc). Cheers, Andrew On Dec 1, 1:47 pm, "David Masover" <d...< at >3mix.com> wrote: --~--~---------~--~----~------------~-------~ acechase 2008-12-02T15:55:56 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10658 Hey Andreas, I just quickly went through your changes and it looks like a good start. A few things : - Could you please open a ticket at http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/overview and upload a .diff file with the patch written for Rails ? Check http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/overview for more help - Patch is missing tests - Those JDBC patches don't really belong to Rails :) Also, it'll really help if you could join the mailing list while we talk about your patch. Most of the people are likely to forget CCing you. But if you don't want to join our lil group, that's not a big deal :) Thanks for working on this. On Sat, Nov 29, 2008 at 3:14 PM, Andreas Gungl <gungl< at >osp-dd.de> wrote: Pratik 2008-12-02T11:47:47 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10657 On Mon, Dec 1, 2008 at 6:54 PM, Michael Koziarski <michael< at >koziarski.com> wrote: Obvious, but how many others are aware of this. Maybe have ActiveSupport emit a warning message when it detects the presence of the JSON gem, telling users who rely on the JSON gem to include it afterwards? This doesn't fiddle with anything, and gives the user great feedback. Best Kenneth Kalmer 2008-12-02T06:50:58 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10656 Not that I'm currently aware off. I'll continue trying to find some fringe cases and in those cases address the issue more clearly than I did this one (and without anger). Thanks everyone On Mon, Dec 1, 2008 at 9:46 PM, Michael Koziarski <michael< at >koziarski.com> wrote: -- Kenneth Kalmer kenneth.kalmer< at >gmail.com http://opensourcery.co.za --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Kenneth Kalmer 2008-12-02T06:46:29 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10655 Yes, that was my thought too, after the first comment. I've come to the conclusion that the second query is unnecessary if we just update the in memory copy directly (without the DB update) and use the Base.update_counters to "safely" update the counters. If the in memory copy is stale, even after the counter cache has updated it, then it would be stale anyways and there is nothing we can do. As long as the database has the correct value then all should be good. One question here, is there any particular reason, why the has_many associations build method only associates the parent object by id rather than by object? This is a potential issue when updating the in memory copy. Although the bi-directional associations may nullify this question. blog = Blog.create puts blog.object_id # => 103230460 post = blog.posts.build puts post.blog.object # => 103511790 Great! A good place to start looking at. Thanks for the link. Thanks, Adam On Dec 1, 12:06 pm, acechase <acech...< at >gmail.com> wrote: --~--~ adamc 2008-12-02T03:13:22 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10654 On Dec 1, 6:57 pm, "Mislav Marohnić" <mislav.maroh...< at >gmail.com> wrote: Thanks! I think you're onto something... the whole stack trace is below, but now I see that rake rails:update did not update the scripts; so it still had my 2.1 version of script/about, wheres the 2.2 version explicitly adds the rails_info directory to the load path. Methinks many other things didn't get updated, either. What's the "right" way to make sure everything gets updated to 2.2.2? Here's the whole stack trace I get when trying to start script/server, for example - maybe I'm missing something obvious? (purple) current: script/server => Booting Thin (use 'script/server webrick' to force WEBrick) => Rails 2.2.2 application starting on http://0.0.0.0:3000 => Ctrl-C to shutdown server Exiting /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ template_handler.rb:11:in `initialize': wrong number of arguments (0 for 1) (ArgumentError) from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_v Jeff 2008-12-02T01:07:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.rails.core