| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restore the 4.0 behaviour for 'sqlite3:///', but deprecate it. We'll
change to the absolute-path interpretation in 4.2.
The current "correct" spellings for in-memory, relative, and absolute
URLs, respectively, are:
sqlite3::memory:
sqlite3:relative/path
sqlite3:/full/path
Substantially reverses/defers fbb79b517f3127ba620fedd01849f9628b78d6ce.
Uncovered by @guilleiguaran while investigating #14495, though that
sounds like a different issue.
|
|
|
|
|
|
|
| |
Follow-Up to https://github.com/rails/rails/pull/14400
This ensures that all tables are removed after each test and thereby
allowing us to run the tests in a random order.
|
|
|
|
| |
See https://github.com/rails/rails/blob/master/activesupport/lib/active_support/notifications.rb#L131
|
| |
|
| |
|
|
|
|
|
| |
Conflicts:
activerecord/test/cases/adapters/sqlite3/sqlite3_adapter_test.rb
|
|
|
|
|
|
|
| |
This fixes broken `rake test_sqlite3_mem` suite for Active Record.
The problem is that that the old database with the schema is lost
when establishing a new connection. Upon reconnting we are left
with a blank database and tests down the line start failing.
|
|
|
| |
Building on the work of #13427 this PR adds a helpful error message to the adapters: mysql, mysql2, and sqlite3
|
| |
|
|
|
|
|
| |
Need to check if valud also respond_to :id before calling it, otherwise
things could explode.
|
|
|
|
|
|
|
| |
We can conditional define the tests depending on the adapter or
connection.
Lets keep the skip for fail tests that need to be fixed.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the `db/` directory is not present on a remote machine it will blow up in unexpected ways with error messages that do not indicate there is a missing directory:
```
SQLite3::CantOpenException: unable to open database file
```
This PR checks to see if a directory exists for the sqlite3 file and if not creates it for you.
This PR is an alternative to #11692 as suggested by @josevalim
|
|
|
|
|
|
|
| |
When mixing postgresql and another adapter like sqlite3 (for dev and test
respectively), the task `db:test:prepare` will fail due to the `enable_extension`
method not being defined in the abstract adapter. This patch simply adds an
empty definition to prevent it.
|
| |
|
| |
|
|
|
|
| |
valid_type? method to abstract_adapter.rb and removed unnecessary method from sqlite3 adapter
|
|
|
|
| |
Now, connection handles the check for valid types so that each database can handle the changes individually.
|
| |
|
|
|
|
| |
To make quote escape binary data correctly it needs the column passed in.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c321b309a9a90bbfa0912832c11b3fef52e71840.
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb
activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb
Reason: failing test
1) Error:
test_valid_column(ActiveRecord::ConnectionAdapters::SQLite3AdapterTest):
NoMethodError: undefined method `column' for
test/cases/adapters/sqlite3/sqlite3_adapter_test.rb:29:in
`test_valid_column'
|
|\
| |
| | |
schema dumper tests now conducted by ActiveRecord::Base.Connection
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit needs to be reverted because it introduces difficulties when
using sqlite3 in development and other databases in production. This
happens because when you create time column in sqlite3, it's dumped as
datetime in schema.rb file.
This reverts commit 57d534ee9e441d078fcc161c0c78ebaa5aacd736, reversing
changes made to 20f049fb50daee0c5e5a69b55b529af5737e8e3f.
Conflicts:
activerecord/test/cases/adapters/sqlite3/sqlite3_adapter_test.rb
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Rationale: this is more readable if serveral queries
are involved in one call. Also, it will be possible
to let AR log EXPLAINs automatically in production
mode, where queries are not even around.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The output in Travis is a bit different. The SQLite
documentation (http://www.sqlite.org/eqp.html) warns
output may change dramatically between releases. I
do not want to mock the result set because I want a
real EXPLAIN to happen. I prefer a test that may fail
in future releases than a test that may give false
positives in future releases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a first implementation, EXPLAIN is highly
dependent on the database and I have made some
compromises.
On one hand, the method allows you to run the most
common EXPLAIN and that's it. If you want EXPLAIN
ANALYZE in PostgreSQL you need to do it by hand.
On the other hand, I've tried to construct a string
as close as possible to the ones built by the
respective shells. The rationale is that IMO the
user should feel at home with the output and
recognize it at first sight. Per database.
I don't know whether this implementation is going
to work well. Let's see whether people like it.
|
|
|
|
| |
You can use multiple databases in your tests without disabling transactional fixtures.
|
| |
|
|
|
|
|
|
|
|
| |
error. Strings tagged as binary will be stored in sqlite3 as blobs. It
is an error to insert binary data to a string column, so an error is
emitted in the log file. People are highly encouraged to track down the
source of the binary strings and make sure that the encoding is set
correctly before inserting to the database.
|
| |
|