coverage report is crashing when running with several connections

[jgebal]

To reproduce:
place 2 connection definitions in database.yml
have a test (that utilizes one of the connections)
execute
plsql-spec --coverage

And you get:

Running all specs from spec/
stmt.c:250:in oci8lib_191.so: ORA-00942: table or view does not exist (OCIError)
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-oci8-2.1.8-x86-mingw32/lib/oci8/cursor.rb:126:in `exec'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-0.5.3/lib/plsql/oci_connection.rb:109:in `exec'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-0.5.3/lib/plsql/oci_connection.rb:94:in `new_from_query'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-0.5.3/lib/plsql/oci_connection.rb:144:in `cursor_from_query'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-0.5.3/lib/plsql/connection.rb:116:in `select_all'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-0.5.3/lib/plsql/sql_statements.rb:10:in `select_all'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-spec-0.4.0/lib/plsql/coverage.rb:106:in `coverage_data'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-spec-0.4.0/lib/plsql/coverage.rb:74:in `report'
        from c:/Ruby193/lib/ruby/gems/1.9.1/gems/ruby-plsql-spec-0.4.0/lib/plsql/coverage.rb:66:in `report'
        from C:/Users/Jacek/RubymineProjects/utplsql_vs_plsql_spec/spec/spec_helper.rb:43:in `block (2 levels) in <top (required)>'
        from C:/Users/Jacek/RubymineProjects/utplsql_vs_plsql_spec/spec/spec_helper.rb:36:in `each'
        from C:/Users/Jacek/RubymineProjects/utplsql_vs_plsql_spec/spec/spec_helper.rb:36:in `block in <top (required)>'

[javornikolov]

Are the two connections to the same database schema?

[jgebal]

Yes. Good point.
Seems like profiler tables are dropped directly after reading from them by connection.
I think it would be better to separate the cleanup from the read of profiler data.
This way we can call cleanup in a separate loop after reading all the data for all connections.

Alternatively we could read once for each unique database-user pair. That would also solve the problem. It could also improve on performance - data would be read only once for each unique database-user.

What do you think?

[jgebal]

The workaround for this issue is to have the plsql profiler tables created and accessible on the database prior to running the tests.
This way ruby-plsql-spec is not dropping the tables but is simply removing the data from it.

[javornikolov]

@jgebal could you check if #22 helps?