On Jul 5, 2010, at 19:56 , rogerdpack wrote:
I don't think this is necessary. Currently the reloader relies on the usage
of require_or_load. Wouldn't it be possible to check at this point whether
the file changed or not? That way watching the tree would not be needed.
Also, this is
Dear all great developers.
I wonder if there is any work being done or thoughts being shared
regarding prepared SQL statements.
Currently I am in heavy need of tuning SQL INSERTS that insert large
(3MB) images into blobs.
I am using rails 2.3.5 with postgres adapter and pg driver.
Any
hi
for what purpose u stored image in database?)
in most cases, its bad choise.
store at file system, and send it with super-puper fast nginx =)
Ivan Nastyukhin
dieinz...@me.com
On Jul 8, 2010, at 2:13 PM, Jarl Friis wrote:
Dear all great developers.
I wonder if there is any work being
I don't quite see how this relates to Ruby on Rails Core, unless you're
wanting to discuss a patch / issue for Rails core. This seems like an
application support question. For Ruby on Rails assistance / discussion,
please discuss on the rubyonrails-talk mailing list.
I agree with Ivan: Do not
Em 08-07-2010 07:38, Ryan Bigg escreveu:
I don't quite see how this relates to Ruby on Rails Core, unless
you're wanting to discuss a patch / issue for Rails core. This seems
like an application support question. For Ruby on Rails assistance /
discussion, please discuss on the rubyonrails-talk
Hello, I've submitted a patch that tests and fixes destroy_all
behaviorhttps://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5069-activerecord-destroy_all-returns-empty-array-instead-of-destroyed-records
.
The regression is that, in Rails 3, `destroy_all` always returned an empty
Case 1:
create_table :users, :id = false, :primary_key = :user_id do |t|
t.integer :user_id
t.string :name
t.timestamps
end
Above migration produces following sql: CREATE TABLE
users (user_id integer, name varchar(255), created_at
datetime, updated_at datetime)
Exactly same sql would be
On Thu, Jul 8, 2010 at 07:58, Rodrigo Rosenfeld Rosas
rr.ro...@gmail.com wrote:
Em 08-07-2010 07:38, Ryan Bigg escreveu:
I don't quite see how this relates to Ruby on Rails Core, unless you're
wanting to discuss a patch / issue for Rails core. This seems like an
application support question.
Hi,
I just updated to edge since I was having a few issues with beta4.
Most of my issues have gone away, but an after_save observer that was
working fine on beta4 simply isn't being called.
class MyObserver ActiveRecord::Observer
observe :post
def after_save(post)
post.flush_cache
On Thu, Jul 8, 2010 at 11:14, Norman Clarke nor...@njclarke.com wrote:
It would be interesting to see the overall performance impact if, for
example, the typical SELECT * FROM table WHERE id = ? LIMIT 1 that
AR generates were prepared rather than just executed directly. I would
guess that
On Jul 8, 2010, at 17:15 , Norman Clarke wrote:
On Thu, Jul 8, 2010 at 11:14, Norman Clarke nor...@njclarke.com wrote:
It would be interesting to see the overall performance impact if, for
example, the typical SELECT * FROM table WHERE id = ? LIMIT 1 that
AR generates were prepared rather
On Thu, Jul 8, 2010 at 12:24, Konstantin Haase k.ha...@finn.de wrote:
On Jul 8, 2010, at 17:15 , Norman Clarke wrote:
On Thu, Jul 8, 2010 at 11:14, Norman Clarke nor...@njclarke.com wrote:
It would be interesting to see the overall performance impact if, for
example, the typical SELECT *
On Jul 8, 2010, at 11:25 AM, Norman Clarke wrote:
On Thu, Jul 8, 2010 at 12:24, Konstantin Haase k.ha...@finn.de
wrote:
On Jul 8, 2010, at 17:15 , Norman Clarke wrote:
On Thu, Jul 8, 2010 at 11:14, Norman Clarke nor...@njclarke.com
wrote:
It would be interesting to see the overall
On Thu, Jul 8, 2010 at 12:47, Rob Biedenharn rob.biedenh...@gmail.com wrote:
On Jul 8, 2010, at 11:25 AM, Norman Clarke wrote:
On Thu, Jul 8, 2010 at 12:24, Konstantin Haase k.ha...@finn.de wrote:
On Jul 8, 2010, at 17:15 , Norman Clarke wrote:
On Thu, Jul 8, 2010 at 11:14, Norman Clarke
Technically this would be a topic for the non-core list unless you had a patch
or something. But...
If I look at the docs and I know the way the adapter's work, the table options
gives the developer full control for all situations. The :primary_key option
will always assume an integer. In the
On Thu, Jul 8, 2010 at 10:29 AM, Konstantin Haase k.ha...@finn.de wrote:
I'm currently rewriting quite a bit of it. Planning to write a post here or
on a blog soon to summarize what I'm changing. When I'm done the reloader
will hopefully only kick in on changes and be able to partially
On Jul 8, 2010, at 18:19 , Xavier Noria wrote:
On Thu, Jul 8, 2010 at 10:29 AM, Konstantin Haase k.ha...@finn.de wrote:
I'm currently rewriting quite a bit of it. Planning to write a post here or
on a blog soon to summarize what I'm changing. When I'm done the reloader
will hopefully
Hi Ken,
My intent is to fix the code. However before that I want to verify
that I am on the right path.
As I have shown in case if I am not happy with my primary key being
id and if I want my primary key to be car_id of type 'string'
there is NO way I can do that. The only way is to have my
Neeraj,
Your missing my point. When you say there is NO way I can do that, your are
incorrect. There is no way you can do it in your examples because you are
taking the :primary_key option to mean something else other than how the
documentation specifies – a simple way to rename the auto
I see you point. And I agree.
However I still think that rails should take some of the
responsibility and should clarify to user following things.
1)
create_table :users, :id = false, :primary_key = :user_id do |t|
t.integer :user_id
t.string :name
t.timestamps
end
Rails should throw an
On Thu, Jul 8, 2010 at 5:23 AM, Mislav Marohnić
mislav.maroh...@gmail.com wrote:
Hello, I've submitted a patch that tests and fixes destroy_all behavior.
The regression is that, in Rails 3, `destroy_all` always returned an empty
array instead of the destroyed records. It slipped through because
On Thu, Jul 8, 2010 at 16:55, Paul Campbell p...@rslw.com wrote:
Most of my issues have gone away, but an after_save observer that was
working fine on beta4 simply isn't being called.
I refactored observers a while ago (April), and was the last to work on them
(to my knowledge). Their tests
On Thu, Jul 8, 2010 at 7:50 PM, Mislav Marohnić
mislav.maroh...@gmail.com wrote:
On Thu, Jul 8, 2010 at 16:55, Paul Campbell p...@rslw.com wrote:
Most of my issues have gone away, but an after_save observer that was
working fine on beta4 simply isn't being called.
I refactored observers a
http://gist.github.com/468116
Unless there's some logical flaw in my benchmark code, it looks like
prepared statements run about 50% faster overall for these types of
queries.
There's a logical flaw in your benchmark code. The situation is a
little more nuanced
On Jul 8, 2010, at 2:23 PM, Neeraj Singh wrote:
I see you point. And I agree.
However I still think that rails should take some of the
responsibility and should clarify to user following things.
1)
create_table :users, :id = false, :primary_key = :user_id do |t|
t.integer :user_id
t.string
25 matches
Mail list logo
