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 grou
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 exampl
On Thu, Jun 12, 2008 at 8:45 PM, frogstarr78 <[EMAIL PROTECTED]> wrote:
>
> 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
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
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 languag
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
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 = YAML::load(ERB.new(IO.read(RAILS_R
> 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) (i
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 d
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 repositor
> 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: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 shou
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, 20
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
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 re
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 d
-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 jus
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 r
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 fr
>
> > 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 w
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 are
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
d
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 earl
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 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?
>
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 n
> 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 pos
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 thro
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:
>
>> config.active_
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
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 pars
On Jun 12, 2008, at 5:47 AM, Rick Olson wrote:
>> 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 though.
>
Something like this is ugly, but
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 m
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.
T
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 opti
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:
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/ticket
> 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 t
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
use
38 matches
Mail list logo
