Forum: Ruby on Rails Tests just deleted my production Database!!! PLEASE HELP

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E0f6f9cfc73d24f1b639786370a97cd9?d=identicon&s=25 Jon (Guest)
on 2006-05-02 11:13
Running the functional tests has deleted the data in my production
database!!! please help!! Using rails 1.1.1 + Oracle.

This is my database.yml file :

development:
  adapter: oci
  host: "V2:x/TIM"
  username: x
  password: x

test:
  adapter: oci
  host: "V2:x/TIM"
  username: x
  password: x

production:
  adapter: oci
  host: "V2:x/TIM"
  username: x
  password: x


How did it happen.  It seems impossible
E0f6f9cfc73d24f1b639786370a97cd9?d=identicon&s=25 Jon (Guest)
on 2006-05-02 11:13
+ using RadRails 0.62
E0f6f9cfc73d24f1b639786370a97cd9?d=identicon&s=25 Jon (Guest)
on 2006-05-02 11:21
I've changed my database.yml to this :

development:
#  adapter: oci
#  host: "V20Z1:x/LIMS2"
#  username: x
#  password: x

test:
  adapter: oci
  host: "V20Z1:x/LIMS2"
  username: x
  password: x

production:
#  adapter: oci
#  host: "V20Z1:x/LIMS2"
#  username: x
#  password: x


and then run the functional tests from within rad rails.  This is the
error i get :

C:\workspace\Scheduler/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:194:in
`establish_connection': development database is not configured
(ActiveRecord::AdapterNotSpecified)

For some reason it wants to use my development database instead of test.
Any ideas why?
50b0c7ff7b5436d6585e8384045cc04a?d=identicon&s=25 Stefan Liden (Guest)
on 2006-05-02 12:09
Jon wrote:
>
> This is my database.yml file :
>
> development:
>   adapter: oci
>   host: "V2:x/TIM"
>   username: x
>   password: x
>
> test:
>   adapter: oci
>   host: "V2:x/TIM"
>   username: x
>   password: x
>
> production:
>   adapter: oci
>   host: "V2:x/TIM"
>   username: x
>   password: x

Never used oracle but if that is your whole database.yml file what is
the difference between the different databases? They seem to be set up
to be the same.
50b0c7ff7b5436d6585e8384045cc04a?d=identicon&s=25 Stefan Liden (Guest)
on 2006-05-02 12:13
I imagine you are missing the following declaration:

database: rails_development
Cd8c9864d88bcafc164d8fdb820cc451?d=identicon&s=25 Chris Richards (chris)
on 2006-05-02 12:24
> Never used oracle but if that is your whole database.yml file what is
> the difference between the different databases? They seem to be set up
> to be the same.

the username for the test database is different, so a diffrent database
is connecte to.

 test:
   adapter: oci
   host: "V2:x/TIM"
   username: x
   password: x

> I imagine you are missing the following declaration:
>
> database: rails_development

Where should this declaration be?
E9fa5947081cf6b45f89a1f07f064418?d=identicon&s=25 Dj T@l (Guest)
on 2006-05-02 13:18
> For some reason it wants to use my development database instead of test.
> Any ideas why?

When running test, rails dumps the development databse schema to the
test
database. So it need to connect to the development database.

HTH
Cd8c9864d88bcafc164d8fdb820cc451?d=identicon&s=25 Chris Richards (chris)
on 2006-05-02 13:47
Dj T@l wrote:
>> For some reason it wants to use my development database instead of test.
>> Any ideas why?
>
> When running test, rails dumps the development databse schema to the
> test
> database. So it need to connect to the development database.
>
> HTH
OK, but that doesn't explain why my development database tables were
emptied.
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-05-02 14:29
All your database tables were emptied because you didn't have
development or production or test databases. You had one database that
you used for everything.

That "database" (or "host" in the case of modern Oracle) entry needs to
be different for each environment, generally corresponding to separate
entries in tsnames.ora, and those three (or however many) databases need
to exist.

If you want three separate databases, you need three separate databases.
Different users on the same database are just that: different users, not
different databases.

For more examples of Oracle database.yml entries, see:

 http://wiki.rubyonrails.org/rails/pages/HowtoConnectToOracle

If you're still not clear on it, you may want to make sure you
understand how to set up and connect to multiple, distinct databases in
Oracle.

For most other databases, the distinction is made in the "database:"
entry in a database.yml block. Oracle's terminology and setup are a bit
different because of the tsnames.ora way of doing things.

Chris Richards wrote:
> Dj T@l wrote:
>>> For some reason it wants to use my development database instead of test.
>>> Any ideas why?
>>
>> When running test, rails dumps the development databse schema to the
>> test
>> database. So it need to connect to the development database.
>>
>> HTH
> OK, but that doesn't explain why my development database tables were
> emptied.
Cd8c9864d88bcafc164d8fdb820cc451?d=identicon&s=25 Chris Richards (chris)
on 2006-05-02 15:06
The username in Oracle determines what tablespace i have access to.

So with the information given in the "test:" section of database.yml it
would be physically impossible to delete any tables that the
"development:" info can be used to access.
Ae60e09b991e7a95e44591eb8756d1f6?d=identicon&s=25 Mike M (Guest)
on 2006-05-02 20:46
A few corrections on Oracle terminology seem to be appropriate:

Steve Koppelman wrote:
> If you want three separate databases, you need three separate databases.
> Different users on the same database are just that: different users, not
> different databases.

What MySQL calls a database, is called a Schema in Oracle. A Schema is
owned by a user.
So you can very well use one database instance with a development, test
and production schema. Just make sure that you have 3 different users
(=schema owners).
As soon as you create a database user (eg user_test), he has his own
schema. If you create a table while connected as this user, the table
will be in the schema of this user.
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-05-02 21:48
Gotcha. It's been six years and a few Oracle versions since I had to
deal with it.

If everything was set up correctly in terms of Oracle client config,
users and schemas, the next thing I'd check is whether the "production"
server really was running against the "production" database or if it was
actually hitting the development schema all along.

There was a bug in RadRails 0.6 and 0.6.1 that in certain situations
caused tests to run against the development db when run from RadRails,
wiping the development db. It's hard to see how this would wipe the
production DB unless maybe the above bug came into play *and* a
misconfiguration had the production server actually running in
development mode against the development schema so that when the
development schema got wiped, the production data (residing in the
development schema) got horked.

Mike M wrote:
> A few corrections on Oracle terminology seem to be appropriate:
>
> Steve Koppelman wrote:
>> If you want three separate databases, you need three separate databases.
>> Different users on the same database are just that: different users, not
>> different databases.
>
> What MySQL calls a database, is called a Schema in Oracle. A Schema is
> owned by a user.
> So you can very well use one database instance with a development, test
> and production schema. Just make sure that you have 3 different users
> (=schema owners).
> As soon as you create a database user (eg user_test), he has his own
> schema. If you create a table while connected as this user, the table
> will be in the schema of this user.
Cd8c9864d88bcafc164d8fdb820cc451?d=identicon&s=25 Chris Richards (chris)
on 2006-05-03 10:25
> If everything was set up correctly in terms of Oracle client config,
> users and schemas, the next thing I'd check is whether the "production"
> server really was running against the "production" database or if it was
> actually hitting the development schema all along.

It was actually wiping my development database, not my production
database.  I'm using RAD Rails 0.6.2 so i can only assume that the same
bug exists.  What do you think?
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-05-03 15:33
Anything is possible. Right after I installed 0.6, I was looking up some
other issue on Trac and saw the reports of the testing-environment bug
and immediately disabled the features. Actually, I still run tests from
the commandline and have that toolbar disabled so I don't really know if
the bug has been squashed  -- for all I know, maybe it's been fixed for
people who are installing standalone RadRails or who went straight to
the 0.6.2 plugin but hasn't been fixed for people who are updating the
plugin from the bad versions.

Maybe the bug is still there, or maybe if you used the testing features
on your app under RadRails 0.6 or 0.6.1 there is a leftover bad pref
setting in your app or in some generated code. You may want to look up
the bug in the RadRails Trac and then have a look at your prefs to see
if the environment setting in question hasn't been set properly.

Chris Richards wrote:
>> If everything was set up correctly in terms of Oracle client config,
>> users and schemas, the next thing I'd check is whether the "production"
>> server really was running against the "production" database or if it was
>> actually hitting the development schema all along.
>
> It was actually wiping my development database, not my production
> database.  I'm using RAD Rails 0.6.2 so i can only assume that the same
> bug exists.  What do you think?
29c5380dd7c19eebebf03bc050c7e27d?d=identicon&s=25 Geoff Hopson (Guest)
on 2006-05-03 18:59
(Received via mailing list)
I got stuffed by something similar yesterday (only a devel database, not
as
big a deal). The problem was that the environment.rb file was overriding
the
Rails ENV variable (not in front of me right now so I don't remember the
right syntax). It's normally commented out, but it was set to
development in
my case, and so it overrode whatever was set in test_helper.rb.

A bit vague, but I'm away from the code right now.
HTH
Geoff
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2006-05-03 18:59
(Received via mailing list)
> The username in Oracle determines what tablespace i have access to.
>
> So with the information given in the "test:" section of database.yml it
> would be physically impossible to delete any tables that the
> "development:" info can be used to access.

Why not if permisions for "development" user allow this?

--
Regards,
Rimantas
--
http://rimantas.com/
312c4c0510a027490c05dc1d32f85c06?d=identicon&s=25 Glenn Stauffer (Guest)
on 2006-05-03 19:01
(Received via mailing list)
On 5/2/06, Steve Koppelman <hatlessnyc@yahoo.com> wrote:
>
> There was a bug in RadRails 0.6 and 0.6.1 that in certain situations
> caused tests to run against the development db when run from RadRails,
> wiping the development db. It's hard to see how this would wipe the
> production DB unless maybe the above bug came into play *and* a
> misconfiguration had the production server actually running in
> development mode against the development schema so that when the
> development schema got wiped, the production data (residing in the
> development schema) got horked.
>

There is a possibility that that is the problem here since he's using
the same Oracle username/schema for production and development.
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (Guest)
on 2006-05-03 19:06
(Received via mailing list)
> It was actually wiping my development database, not my production
> database.  I'm using RAD Rails 0.6.2 so i can only assume that the same
> bug exists.  What do you think?

I think it would be worthwhile to have a look at the radrails log to see
if
we can learn more.

Thibaut
This topic is locked and can not be replied to.