With fastcgi, the routes file entries need to look like:
map.connect “:controller/:action/:id”
since the public directory is mapped in apache under the url /club/
With scgi, the same route needs to be:
map.connect “club/:controller/:action/:id”
I thought, hey, why don’t I control this with a variable, so in my
routes
file I have:
webrick and fastcgi version: base = ‘’
scgi version: base = ‘club/’
base = ‘club/’
…
map.connect “#{base}:controller/:action/:id”
So, if I want to run scgi, I just modify one line.
I’d like to now automate it, and detect somehow if the code is being run
by
SCGI, and set my ‘base’ variable on the fly.
Does anybody have an idea how to detect if the code is being called by
SCGI?
This may or may not help you but I thought I’d bring it to your
attention anyhow:
I recently had to come up with a way to make sure I could run SCGI
under apache2 without changing may app’s routes. My solution was to
mangle the REQUEST_URI before it was interpreted by rails routing code.
Its really simple to understand, just check the README and the
init.rb - it might give you an idea for how to solve your problem
without altering routes.
Thanks, guys. That was helpful. I found the
Kernel.caller[-1] =~ /scgi/
approach worked for fixing things in routes.rb, but stuff related to
asset
paths like javascript_include_tag is broken (i.e. Returns urls like
“/javascripts/…” instead of “/club/javascripts/…”)
Trevor, your code was very helpful. It got me reading the Rails source,
and
I think I’ve concluded that the reason you had to do what you did, and
the
reason I’m having trouble is due to a bug in request.relative_url_root,
which, in the fastcgi case would starting with env[“SCRIPT_NAME”] ==
‘/club/dispatch.fcgi’, and then whacks off the /dispatch.fcgi portion
via a
bit too aggressive regular expression, because in the scgi case,
env[“SCRIPT_NAME”] == ‘/club’, and it returns ‘’ in that case.
Maybe we can fix everybody’s issues by fixing relative_url_root. I’ll
experiment with a patch to see.
Example 1:
class MyModel < ActiveRecord::Base
def sum_i_j
i + j
end
end
Example 2 I think you’ll have to go with SQL. Better to let the db
handle such a complex aggregation, I imagine it would be much faster
than doing it in Rails (though you definitely could. Just create a
method like I did in Example 1 and perform your calculations.
As an aside, I don’t think it’s the best idea to put these kinds of
methods in your model. They certainly can go there, and for trivial
things (Ex 1) I don’t have any really problem doing it. For more
complex reports, I think it’d be best to have another class, maybe
MyObjectReport that just acts as a view of a MyObject.
Example 2 I think you’ll have to go with SQL. Better to let the db
handle such a complex aggregation, I imagine it would be much faster
Why the upfront preference to have the db do the complex calculation
work? Ruby is far more pleasant to work with than SQL. Far more
flexible too.
“I imagine it would be much faster”
Of course it depends entirely on just how complex it is. My preference is to use Ruby wherever possible. If I’m performing
massive calculations, I’d give it a go in Ruby and in SQL, and if the
SQL is significantly faster use that instead.
The patch was accepted. Zed, give this a try and see if it eliminates
your
need for double route entries.
Dave
Here was the email: #3070: [PATCH] Apache/scgi matches routes wrong, generates urls wrong
when
under
subpath (like /collaboration/hieraki/:controller/…)
----------------------------------------------------------------------±----
Reporter: [email protected] |
Owner: David
Type: defect |
Status: new
Priority: normal |
Milestone:
Component: ActionPack |
Version: 0.14.3
Severity: major |
Resolution:
Keywords: relative_url_root scgi fcgi Apache Alias subpath mapping |
----------------------------------------------------------------------±----
Comment (by bitsweat):
(In [3237]) More robust relative url root discovery for SCGI
compatibility. This solves the ‘SCGI routes problem’ – you no longer
need to prefix all your routes with the name of the SCGI mountpoint.
References #3070.