On Nov 22, 4:10 pm, RVince <rvinc...@hotmail.com> wrote:
> Yes, ORMs are wonderful, once you learn the abstraction layer. But --
> and I know some will take offense at this -- there are things to avoid
> in learning Ruby, and just use the old tried-n-true (many things, like
> using straight Javascript for most of the Ajax-like things you want to
> do, or for db-query-b ased algorithms, like I am trying to accomplish
> here, sticking with as straight of an sql interface as possible). This
> is true of most languages, if you can learn a more generic means of
> implementing the language, you are not only up-to-speed faster, BUT,
> you generally have a finer-grained control over what you ware
> implementing.
>
> The algorithm I am looking to sweeten of:
>
> # Is the associate in the list - if not, make it the person at
> the top of the list.
> @up = Up.find(params[:id]) #get the individual up record which
> has the associate and channel
> @associate = @up.associate #specify ref to the associate in question
> #see if this associate is in the current list
> @Qplayers = Qplayer.find_by_sql(["select * from qplayers where
> associate_id=? and channel_id=? and
> inlist=1",@associate.id,@associate.channel_id])
> if @Qplayers[0].blank? #if the associate from the up in the row is in
> the list, it wont be blank
> @Qplayers = Up.find_by_sql(["select * from qplayers where
> channel_id=? and inlist=1 order by battingorder ASC",@up.channel_id])
> @Qplayer = @Qplayers[0]
> @associate = @Qplayer.associate
> end
>
> I'm not sure can be more clearly expressed in a "sweeter" way,
> especially if the criteria changes in the future -R.Vince
>
I wouldn't resort to find_by_sql for this - just a normal find :all
keeps things clean, and plays nicely with scopes and so on. It seems
to me that you could make this a little more succinct by playing
around with named_scope and similar tools, eg add
named_scope :in_list, :conditions => {:inlist => true}
named_scope :in_channel, lambda {|channel_id| {:conditions =>
{:channel_id => channel_id}}}
to Qplayer
And then you can write something like
@qplayer = @associate.q_players.in_list.in_channel
(@associate.channel_id).first
if !...@qplayer
@qplayer = Qplayer.inlist.in_channel
(@up.channel_id).find :first, :order -> 'batting_order asc'
end
Fred
> On Nov 22, 10:59 am, Eno <ra...@bitblit.net> wrote:
>
>
>
> > On Sun, 22 Nov 2009, RVince wrote:
> > > See, I don't htink there IS an easier way -- just a Ruby-occluded way
> > > called .find_by_sql(["select ..."])
>
> > > A lot of this syntactic sugar really gets in the way. Rails is great,
> > > as a web framework -- far superior to something like Struts. But in
> > > the end, it;s back to JRuby, writing the back end in the C-like
> > > syntax of Java, and avoiding Ruby and it's idioms, making use of Rails
> > > this way.
>
> > I wasn't saying use Rails, just ActiveRecord. And DBI is fairly light and
> > gives you database independance.
>
> > You know what an ORM is right? That's really nice syntactic sugar.
>
> > --
> > A
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=.
