On 12 Jun 2008, at 03:56, DHH wrote:
Please, for the sake of sanity, do not change this from the old way
unless
you have a better reason than It's DRYer
Just for the sake of argument, yaml configs don't have to be repetitive:
defaults: defaults
adapter: mysql
encoding: utf8
Just for the sake of argument, yaml configs don't have to be repetitive:
defaults: defaults
That's also a lot harder to read and write, especially for newbies. I
definitely support an all-ruby approach. Supporting some generic hash
merging, as Scott suggested, might not be a bad idea
If @@request_forgery_protection_token is not set in
ActionController::Base, it can raise an InvalidAuthenticityToken error
when one controller creates a form that will post in another
controller.
Patch and better explanation here:
On Thu, Jun 12, 2008 at 3:47 AM, Rick Olson [EMAIL PROTECTED] wrote:
In a similar vein: last night at the Baltimore ruby group, John
Trupiano suggested some way of merging the yml files from the
geminstaller gem with Rails' gem configurations.
I've wanted to provide a non-YAML config option
Considering Rick referenced me, and I've made nary an appearance on
this particular list, I figured I'd chime in. I like YAML as a
portable format. It's not uncommon (especially for us) to have
solutions that aren't completely ruby/rails, and where it's helpful to
have portable configuration.
Why was yaml used in the first place?
On Wed, Jun 11, 2008 at 9:56 PM, DHH [EMAIL PROTECTED] wrote:
Please, for the sake of sanity, do not change this from the old way
unless
you have a better reason than It's DRYer
I think that's a perfectly valid reason. Not just that it's more dry,
On Jun 12, 2008, at 9:28 AM, Chad Woolley wrote:
So, I hope Rails still natively supports the old YAML format after
this patch, to support old tutorials, and to provide a standardized
option when it is needed, such as Rails parsing geminstaller.yml if it
exists, or a hosting company parsing
On Thu, Jun 12, 2008 at 7:45 AM, John Trupiano [EMAIL PROTECTED] wrote:
This is, in fact, the same idea Rick mentioned that I proposed. I
suggested moving gem configuration out into a YAML file (or at least
adding a hook for this). Why? Because then capistrano could read in
that file and
On Wed, Jun 11, 2008 at 2:39 PM, Adam Keys [EMAIL PROTECTED] wrote:
## What's it look like?
In config/environment.rb:
config.active_record.connection.configure do |db|
db.adapter = 'mysql'
db.encoding = 'utf8'
end
In config/development.rb:
On Jun 12, 2008, at 11:40 AM, James Adam wrote:
I guess this boils down to - why generate the Hash, when just writing
the Hash is pretty much equally readable? Do we get some benefit using
the block/DSL-style syntax? If not, the implementation could perhaps
be simpler.
Running it through a
Why was yaml used in the first place?
Because I thought dammit, we gotta use YAML for something -- aka not a
good reason at all ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post
Reading the database configuration in for use in the db:console will
now require loading the entire framework! Sweet!
On Thu, Jun 12, 2008 at 12:38 PM, DHH [EMAIL PROTECTED] wrote:
Why was yaml used in the first place?
Because I thought dammit, we gotta use YAML for something -- aka not a
On Jun 12, 2008, at 12:54 PM, Duncan Beevers wrote:
Reading the database configuration in for use in the db:console will
now require loading the entire framework! Sweet!
On Thu, Jun 12, 2008 at 12:38 PM, DHH [EMAIL PROTECTED]
wrote:
Why was yaml used in the first place?
Because I
In a different box:
rm -rf ~/.gem
gem --version
1.1.1
sudo gem install activerecord-oracle-adapter --source
http://gems.rubyonrails.org
ERROR: could not find activerecord-oracle-adapter locally or in a repository
What gives?
Sandro
On Jun 11, 9:49 pm, Chad Woolley [EMAIL PROTECTED]
On Jun 12, 2008, at 3:13 PM, Ezra Zygmuntowicz wrote:
I have to chime in here and plead for you to leave the database.yml
alone. Or if you must use ruby config, please leave the db.yml
working. If the credentials/config is only in ruby and in the local
variable format you showed
I just entered this ticket.
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/404-named_scope-bashes-critical-methods
It turns out that in an ActiveRecord model like this
Model ActiveRecord::Base
named_scope :public
private
def private_method
end
public
I am also skeptical about this switch. It works as is, and supporting
both methods will just confuse people. Ezra's point about formatting
is also a good point. Most other languages have a yaml parsing
library, but if they have to parse a ruby config, it's not really an
elegant solution. If we
I see significant downsides to the pure ruby config:
It seems there are a lot of deployment-time concerns here. Would it
help if there was a Rake task to dump database.yml for a given
environment?
The assumption here is that all servers in a given environment are
configured with the
Duncan Beevers wrote:
Reading the database configuration in for use in the db:console will
now require loading the entire framework! Sweet!
I think Duncan has a good, albeit snarky, point. If we do switch to the
ruby-based config we have to make sure that we dont slow other parts of
the
Ezra Zygmuntowicz wrote:
I see significant downsides to the pure ruby config:
4. there are countless daemons and plugins that read the database.yml
to get the db config info. how will these daemons now get said info
without loading all of the rails environment?
I thought rails
-1
If the database credentials reside in the ruby environment files then
we would be committing our database passwords into the repository.
Anyone with read access to the source code now has credentials to the
db. I'm skeptical of overly paranoid security measures, but this to me
this
On Thu, Jun 12, 2008 at 1:25 PM, Adam Keys [EMAIL PROTECTED] wrote:
It seems there are a lot of deployment-time concerns here. Would it
help if there was a Rake task to dump database.yml for a given
environment?
This ALMOST sounds like a good idea, but this really would be non-DRY,
in a
On Thu, Jun 12, 2008 at 1:23 PM, SandroDS [EMAIL PROTECTED] wrote:
In a different box:
rm -rf ~/.gem
gem --version
1.1.1
sudo gem install activerecord-oracle-adapter --source
http://gems.rubyonrails.org
ERROR: could not find activerecord-oracle-adapter locally or in a repository
On Thu, Jun 12, 2008 at 3:10 PM, matthew deiters [EMAIL PROTECTED] wrote:
If the database credentials reside in the ruby environment files then
we would be committing our database passwords into the repository.
There's no reason to keep the database credentials in environment.rb.
Just throw
Awesome - so I get to distribute the concept of database configuration
into multiple files. Best yet each rails project can come up with it's
own conventions on what it should call this file and what should go in
it.
On Jun 12, 2008, at 5:37 PM, Scott Bronson wrote:
On Thu, Jun 12,
On Thu, Jun 12, 2008 at 3:47 PM, matthew deiters [EMAIL PROTECTED] wrote:
Awesome - so I get to distribute the concept of database configuration
into multiple files.
You do currently. Is that a problem?
Best yet each rails project can come up with it's
own conventions on what it should
What's nice about this patch is that you can put the global configs in
environment.rb (UTF8, db host, database name) and leave just the
sensitive ones out of source control (username, password).
This argument has been given a few times. Am I the only one who
considers the db host en
On Thu, Jun 12, 2008 at 3:37 PM, Scott Bronson [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 3:10 PM, matthew deiters [EMAIL PROTECTED]
wrote:
If the database credentials reside in the ruby environment files then
we would be committing our database passwords into the repository.
On Thu, Jun 12, 2008 at 4:04 PM, Lawrence Pit [EMAIL PROTECTED] wrote:
What's nice about this patch is that you can put the global configs in
environment.rb (UTF8, db host, database name) and leave just the
This argument has been given a few times. Am I the only one who
considers the db host
To keep this discussion on track, forget I said that abou the db host
and db name. :) But there's no reason to keep the adaptor, encoding,
or socket location secret.
I don't want you to know /anything/ about the databases I'm using.
Including the adapter and socket location(s) (if I
Btw, what about email credentials? Currently the only way to define the
smtp_settings for ActionMailer::Base is via ruby code. If we're sticking
to database.yml, shouldn't we have an email.yml as well?
sure, I can do e.g.:
ActionMailer::Base.smtp_settings =
On Jun 12, 2008, at 1:13 PM, Ezra Zygmuntowicz wrote:
I see significant downsides to the pure ruby config:
1. cannot read from non ruby languages.
I concur with Ezra on this. It's very nice to have the database config
in a single place that other applications in other languages can
Sure you can.
It'll just be a larger pain in the ass.
On Fri, Jun 13, 2008 at 9:47 AM, Michael Schoen [EMAIL PROTECTED] wrote:
On Jun 12, 2008, at 1:13 PM, Ezra Zygmuntowicz wrote:
I see significant downsides to the pure ruby config:
1. cannot read from non ruby languages.
I
config.active_record.configure do |db|
db.database = 'test_app_production'
db.socket = IO.popen(mysql --help) {|f| f.read() =~ /^socket(.+)
$/ $1.strip }
db.credentials = #{ENV[home]}/.my.cnf
end
Good idea or not, I'm just throwing it out there. Not that you
couldn't have done this
I originally posted this in the normal rails group, but no replies...
In the docs for dom_id, this is given as an example...
dom_id(Post.new(:id = 45)) # = post_45
This doesn't work and I don't see how it's supposed to work. :id is a
protected attribute, meaning it will be nil.
The example
HOT PHOTOS AND VIDEOS COME FROM INDIA
http://www.funnygames2all.page.tl/
http://www.rojahot1.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this
36 matches
Mail list logo
