[ANN] Rails RC5 (0.14.4): Next stop one-oh (really, this tim

Looks fine to me. On ruby-forum.com too. Tell it to Yahoo and/or fix
your MUA…

csn

— Stephen W. removed_email_address@domain.invalid wrote:

Steve


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I got an Application Failed to start after “rake update_javascripts” on
a
Typo install, but restarting Apache fixed it.
Ernie

On 08/12/05, David Heinemeier H. removed_email_address@domain.invalid
wrote:

It’s been a month since we promised that RC4 would be the final
countdown. And counting down we have. We’ve fixed a ton of major,
minor, and aesthetic issues and now have a package that we would be
very proud to call 1.0. No, it’s not completely spotless. A project of
this size with thousands of programmers using it for every application
type under the moon will never be. But it’s Pretty Damn Good.

The version of Transaction::Simple bundled with ActiveRecord in the
lib/…/vendor directory is badly out of date and should either (a) be
removed, (b) updated, or © further qualified in namespace. It is my
opinion that because removal is the better option, because it will
allow the update of Transaction::Simple separately from ActiveRecord.
New features have been added to Transaction::Simple that are required
by PDF::Writer, and the version of ActiveRecord included by
Transaction::Simple conflicts with this. I have seen reports that the
removal of the vendor version of Transaction::Simple and using the
RubyGems installed or putting a new version (which is multiple files,
now) in vendor are both acceptable.

I do not plan on changing the interface of Transaction::Simple from
what is present except through addition, although I may be changing
the implementation as I understand what may be possible moving forward
to reduce object graph overload and simplify object handling that I
have discovered in PDF::Writer.

-austin

Austin Z. * removed_email_address@domain.invalid
* Alternate: removed_email_address@domain.invalid

I didn’t mean to be so flip. But I don’t see what the problem is, or how
I caused it. The subject
for this thread has gotten pretty mangled - re’s before after [Rails] or
[ANN] and the line
getting truncated. Despite that, ruby-forum.com and gmail don’t appear
to have a problem keeping
all the messages together in one thread. Also, since I’m using Yahoo
Mail, I don’t know what I can
“fix”.

csn

— Stephen W. removed_email_address@domain.invalid wrote:

removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Hi,

2005/12/8, Rick O. removed_email_address@domain.invalid:

Did you edit the database.yml file?

Same problem here in my win-dev-version. I have mysql 4.0.25 and get the
error
Mysql::Error (Access denied for user: ‘@localhost’ to database
‘@’):…
I can’t easily upgrade to MySQL 4.1, because on the server is running
4.0.x too.

I didn’t change the database.yml-file.

On creating a new project, I looked into the database.yml-file, where
is a comment

MySQL (default setup). Versions 4.1 and 5.0 are recommended.

But that can’t be true, can it?

Greetings,
Beate

Stephen W. wrote:

PLEASE fix your MUA. Every time you reply you’re creating a new thread.
You’ve scattered a single thread into 3 or 4 threads.

That’s an exaggeration, unless your copy of Thunderbird is behaving a
lot worse than mine. I see one split of the thread, at the point you
were complaining about, and I can’t see the difference in CSN’s message
headers between the messages that appear as threaded and the one that
appeared as the start of a new thread. The ‘offending’ message had an
In-Reply-To: header with the correct message ID.

What’s your analysis? I’m inclined to blame my MUA.

regards

Justin

Beate P. wrote:

get a error… Access denied for user: ‘@localhost’ (Using password: NO)

I didn’t change the database.yml-file.

On creating a new project, I looked into the database.yml-file, where
is a comment

MySQL (default setup). Versions 4.1 and 5.0 are recommended.

But that can’t be true, can it?

Greetings,
Beate

I also see this with MySQL 4.0.13 on Windows XP:

ruby script/generate scaffold Monkey
exists app/controllers/
exists app/helpers/
create app/views/monkeys
exists test/functional/
dependency model
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/monkey.rb
create test/unit/monkey_test.rb
create test/fixtures/monkeys.yml
Unknown database ‘@’

In script\console:

C:\radrails_0.5.1\workspace\Test>ruby script\console
Loading development environment.

m = Monkey.new
Mysql::Error: Unknown database ‘’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/vendor/mysql.rb:510:in read' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/vendor/mysql.rb:152:inreal_connect’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/connection_adapters/mysql_adapter.rb:45:in mysql_connection' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/connection_adapters/abstract/connection_specification.rb:145:insend’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/connection_adapters/abstract/connection_specification.rb:145:in
connection_wi thout_query_cache=' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/query_cache.rb:54:inconnection=’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/connection_adapters/abstract/connection_specification.rb:106:in
retrieve_conn ection' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/connection_adapters/abstract/connection_specification.rb:20:inconnection’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/base.rb:734:in columns' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/base.rb:1663:inattributes_from_column_definition’
from
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor
d/base.rb:1185:in initialize_without_callbacks' from c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/active_recor d/callbacks.rb:236:ininitialize’
from (irb):1:in `new’
from (irb):1

Doing the same on another XP machine, with MySQL 4.1, was fine.

regards

Justin

I’ve run across a problem. My host installed the new gems, so my
production application got pushed to 14.4.

After fixing one small startup glitch, all seemed well - everything
seems to work. But now I am getting what looks like a MySql
connection error (error text below). I use the utf-8 hack where the
connection needs to ‘SET NAMES UTF8’ for every connection (as
discussed here on the list). Worked fine for months.

It looks like after running fine for a while, something happens (runs
out of connections?) and throws the error. If I restart the server
(lighty), all works again. But I have no doubt I will see the
problem again.

Ideas?

NoMethodError (undefined method []' for nil:NilClass): /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/ active_record/connection_adapters/mysql_adapter.rb:322:inconnect’
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/
active_record/connection_adapters/mysql_adapter.rb:174:in reconnect!' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/ active_record/connection_adapters/abstract/ connection_specification.rb:103:inretrieve_connection’
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/
active_record/connection_adapters/abstract/
connection_specification.rb:20:in connection' /lib/utf8.rb:12:inconfigure_charsets’
/lib/utf8.rb:11:in suppress' /lib/utf8.rb:11:inconfigure_charsets’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/filters.rb:354:in send' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/filters.rb:354:incall_filters’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/filters.rb:350:in each' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/filters.rb:350:incall_filters’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/filters.rb:339:in before_action' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/filters.rb:331:inperform_action_without_benchmark’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/benchmarking.rb:69:in perform_action_without_rescue' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/benchmarking.rb:69:inmeasure’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/benchmarking.rb:69:in perform_action_without_rescue' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/rescue.rb:82:inperform_action’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/base.rb:369:in send' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/ action_controller/base.rb:369:inprocess_without_session_management_support’
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.1/lib/
action_controller/session_management.rb:116:in process' /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/dispatcher.rb: 38:indispatch’
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/
fcgi_handler.rb:141:in process_request' /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/ fcgi_handler.rb:53:inprocess!’
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/
fcgi_handler.rb:52:in each_cgi' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.6.1/./fcgi.rb:597:ineach’
/usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.6.1/./fcgi.rb:597:in
each_cgi' /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/ fcgi_handler.rb:52:inprocess!’
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.4/lib/
fcgi_handler.rb:22:in `process!’
/public/dispatch.fcgi:24

you can determine whether you have run out of connections by running

mysqladmin.exe -u root -p extended

and checking ‘Threads_connected,’

| Threads_connected | 3 |
| Threads_created | 3 |
| Threads_running | 1 |

Then compare ‘Threads_connected’ with ‘max_connections’ by
doing a ‘show variables;’ so that you see something like this:


| max_connect_errors | 10
| max_connections | 50
| max_delayed_threads | 20

If ‘Threads_connected’ is at or close to ‘max_connections’ then reset
‘wait_timeout’ in the my.ini file to something like 30 so that the
connections are automatically reused after 30 seconds of inactivity.

wait_timeout=30

The default wait_timeout is 8 hours, which means a connection will
not be recycled for 8 hours after it was last used unless it is
explicitly closed.

Brett W. wrote:

out of connections?) and throws the error. If I restart the server
(lighty), all works again. But I have no doubt I will see the problem
again.

Ideas?
[snip]

Yes. But it can’t be the answer to upgrade to mysql 4.1. That would
cause too much trouble. I know lots of applications (in php or so)
which have problems under 4.1, so not everybody can easily upgrade
his/her server to 4.1.

Perhaps a downgrade with ActiveRecord may help?

Beate

Beate P. wrote:

Yes. But it can’t be the answer to upgrade to mysql 4.1. That would
cause too much trouble. I know lots of applications (in php or so)
which have problems under 4.1, so not everybody can easily upgrade
his/her server to 4.1.

I mentioned that the same thing worked with 4.1 as evidence that I was
trying to do the right thing with 4.0, not as a suggestion that you
should upgrade. Sorry if I gave that impression.

Perhaps a downgrade with ActiveRecord may help?

Looking at where the exception occurs, the file

activerecord-1.13.1\lib\active_record\vendor\mysql.rb

appears to be the pure ruby mysql driver. Looking at the log comments in
SVN, it has local patches by the Rails team.

From the Rails MySQL adapter code, it appears that this local copy will
only be used if no other MySQL driver is present.

In the previous version of ActiveRecord, there were mysql.rb and
mysql411.rb files, which were both loaded.

Renaming the mysql.rb file in
activerecord-1.13.1\lib\active_record\vendor and copying across the
previous version allows me to connect to the database, but might
introduce other problems… I should really look into how to run the
ActiveRecord unit tests.

You could give it a try, and I’m mentioning this in the hope that it
will help the Rails team to home in on the problem and produce a proper
fix.

regards

Justin

On 12/9/05, Brett W. removed_email_address@domain.invalid wrote:

out of connections?) and throws the error. If I restart the server
(lighty), all works again. But I have no doubt I will see the
problem again.

Ideas?

NoMethodError (undefined method `[]’ for nil:NilClass):
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.1/lib/

I believe this is the error I got as well (running on TxD with mysql
and on 0.14.4). I didn’t go home last night, so didn’t get a chance
to try it out.

Joe

Lou, thanks. I will monitor the connections throughout the day and
see what happens. Currently the max_connections are 128, and the
threads are at 16. The wait_timeout is 600 (my guess is I can’t
tweak that value on TextDrive).

I still think this might point to a potential issue with 14.4, as
this behavior didn’t start occurring until the upgrade.

I will monitor and see what happens.

Thanks,
Brett

Works great on FireFox, but not on Safari 2.0.2. On Safari, it
doesn’t drop down at all, just sits there.

Brett

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Beate P. wrote:

Yes. But it can’t be the answer to upgrade to mysql 4.1. That would
cause too much trouble. I know lots of applications (in php or so)
which have problems under 4.1, so not everybody can easily upgrade
his/her server to 4.1.

Use the C bindings:
gem install mysql

On Dec 9, 2005, at 7:17 AM, Justin F. wrote:

You could give it a try, and I’m mentioning this in the hope that
it will help the Rails team to home in on the problem and produce a
proper fix.

At this point, barring a bug in the AR adapter, it’s up to the MySQL
driver developers. The updated mysql driver that has replaced the
old driver + mysql411 is more compatible, but clearly isn’t good enough.

Use the C bindings.

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDmeERAQHALep9HFYRAldIAKCpQ4P3rtLd/KYdchNgKm2PvoiqogCfWVYc
ixf39HSmiVk36DlhN6FZFp4=
=dTcI
-----END PGP SIGNATURE-----

On 12/9/05, Jeremy K. removed_email_address@domain.invalid wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Beate P. wrote:

Yes. But it can’t be the answer to upgrade to mysql 4.1. That would
cause too much trouble. I know lots of applications (in php or so)
which have problems under 4.1, so not everybody can easily upgrade
his/her server to 4.1.

Use the C bindings:
gem install mysql

That may not be an option for everyone. Are there other options, or is
MySQL + Rails now a doubtful choice?

James

The error is definitely still occurring for me - it’s happened 3
times since this morning.

It might be a database connection timeout like Joe mentioned.
Looking that the logs, it seems like the error occurs after a period
of inactivity (usually over 10 minutes). The connection timeout at
TxD is 10 minutes, so this fits.

Is it time to open a ticket on this?

Brett

It seems there is a problem with pure Ruby version of Mysql driver that
comes
with 0.14.4. I’ve opened a ticket

http://dev.rubyonrails.org/ticket/3160

Kent.

David Heinemeier H. wrote:

It’s been a month since we promised that RC4 would be the final
countdown. And counting down we have. We’ve fixed a ton of major,
minor, and aesthetic issues and now have a package that we would be
very proud to call 1.0. No, it’s not completely spotless. A project of
this size with thousands of programmers using it for every application
type under the moon will never be. But it’s Pretty Damn Good.

[snip]

“pragdave”, et. al. – is there a corresponding update to “Agile Web
Development with Rails” in the works? Those gerbils must be chomping at
the bit to build me a copy. :slight_smile:


M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

Jeremy K. wrote:

driver + mysql411 is more compatible, but clearly isn’t good enough.

Use the C bindings.

jeremy

The problem in connecting is not in the AR adapter (I have checked the
parameters being passed in to the real_connect call) - it happens within
the real_connect method of the mysql.rb driver.

Looking harder at this, it is clear that the problem is not with the
driver in its original form (version 0.2.6) from

http://www.tmtm.org/en/ruby/mysql/README_en.html

but with the patch applied to it to make it work with MySQL 4.1.1 and
above.

Whereas the mysql411.rb overlay that you used in the previous release
candidate did a check based on the MySQL version string, the patch looks
at flags in the @server_capabilities. The flags themselves look
sensible; for me, on first connection to MySQL 4.0.13, they are:

Server capabilities: 8236
Long password: false
Found rows: false
Long flag: true
Connect with db: true
No schema: false
Compress: true
ODBC: false
Local files: false
Ignore space: false
Protocol 41: false
Interactive: false
SSL: false
Ignore SIGPIPE: false
Transactions: true
Reserved: false
Secure connection: false

but the way they are being used to switch between old and new (4.1.1+)
behaviour is totally broken:

CLIENT_PROTOCOL_41 = 1 << 9

CLIENT_SECURE_CONNECTION = 1 << 15

PROTO_AUTH41 = CLIENT_PROTOCOL_41 | CLIENT_SECURE_CONNECTION

if !@server_capabilities & PROTO_AUTH41 # ***** !!!
# old behaviour
else
# new behaviour
end

This broken condition (which always evaluates to false, because
@server_capabilities is a Fixnum, so !@server_capabilities is false)
appears in lines 130, 208, 273, 287, 405 and 419.

At line 144, there’s even:

   if PROTO_AUTH41

(and the preceding line, from the original code:

 if db and @server_capabilities & CLIENT_CONNECT_WITH_DB != 0 then

shows how to express these conditions properly).

So… it looks as if this patch was never tested with MySQL 4.0. Given
the elementary nature of the errors, the whole patch needs very careful
inspection.

regards

Justin

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

Sponsor our Newsletter | Privacy Policy | Terms of Service