- 06 2月, 2016 1 次提交
- 01 2月, 2016 2 次提交
-
-
由 Yasuo Honda 提交于
for those who already migrated to Rails 5.0.0 beta
-
由 Yasuo Honda 提交于
to support Oracle database which only supports 30 byte identifier length
-
- 15 1月, 2016 3 次提交
-
-
由 schneems 提交于
😳 -
由 Sean Griffin 提交于
-
- 12 1月, 2016 2 次提交
-
-
由 schneems 提交于
This PR addresses the issue described in https://github.com/rails/rails/pull/22967#issuecomment-170251635. If the database is non empty and has no new migrations than `db:migrate` will not set the environment. This PR works by always setting the environment value on successful `up` migration regardless of whether or not a migration was actually executed.
-
由 schneems 提交于
-
- 08 1月, 2016 2 次提交
-
-
由 schneems 提交于
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
-
由 schneems 提交于
This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd. It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large. To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
-
- 17 12月, 2015 2 次提交
-
-
由 Abdelkader Boudih 提交于
-
由 Sean Griffin 提交于
This test was failing when run on Windows using PostgreSQL. Depending on the OS (and 32 vs 64 bit), this type could be a `BigNum`. We could loosen the assertion to `Numeric`, but if the value is equal to the expected, and responds to `bitlength` properly, who cares?
-
- 15 12月, 2015 1 次提交
-
-
由 Matthew Draper 提交于
Apart from specific versioning support, our tests should focus on the behaviour of whatever version they're accompanying, regardless of when they were written. Application code should *not* do this.
-
- 20 11月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
This reverts commit 8246b593. There was concern about this modifying the behavior of past migrations. We're going to add an way to modify the migration generator instead.
-
由 Sean Griffin 提交于
It's often the case that you want to have an option that you cannot specify at the database level, but want applied to *all* tables that you create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to not have to limit text columns to length 171 for indexing when using utf8mb4. This allows an easy way to specify this in your database configuration. While this change affects both MySQL and MySQL2, the test only covers MySQL2, as the legacy mysql adapter appears to always return ASCII strings, and is tangential to what we're actually doing.
-
- 18 11月, 2015 1 次提交
-
-
由 Sam Davies 提交于
- key was a poor choice of name. A key implies something that will unlock a lock. The concept is actually more like a 'lock identifier' - mysql documentation calls this a 'lock name' - postgres documentation calls it a 'lock_id' - Updated variable names to reflect the preferred terminology for the database in question
-
- 05 11月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 31 10月, 2015 2 次提交
-
-
由 Aaron Patterson 提交于
we should be using a countdown latch instead of rolling our own busy-loop.
-
由 Sam Davies 提交于
- Addresses issue #22092 - Works on Postgres and MySQL - Uses advisory locks because of two important properties: 1. The can be obtained outside of the context of a transaction 2. They are automatically released when the session ends, so if a migration process crashed for whatever reason the lock is not left open perpetually - Adds get_advisory_lock and release_advisory_lock methods to database adapters - Attempting to run a migration while another one is in process will raise a ConcurrentMigrationError instead of attempting to run in parallel with undefined behavior. This could be rescued and the migration could exit cleanly instead. Perhaps as a configuration option? Technical Notes ============== The Migrator uses generate_migrator_advisory_lock_key to build the key for the lock. In order to be compatible across multiple adapters there are some constraints on this key. - Postgres limits us to 64 bit signed integers - MySQL advisory locks are server-wide so we have to scope to the database - To fulfil these requirements we use a Migrator salt (a randomly chosen signed integer with max length of 31 bits) that identifies the Rails migration process as the owner of the lock. We multiply this salt with a CRC32 unsigned integer hash of the database name to get a signed 64 bit integer that can also be converted to a string to act as a lock key in MySQL databases. - It is important for subsequent versions of the Migrator to use the same salt, otherwise different versions of the Migrator will not see each other's locks.
-
- 09 9月, 2015 1 次提交
-
- 23 8月, 2015 2 次提交
- 17 3月, 2015 1 次提交
-
-
由 Brandon Weiss 提交于
I’m renaming all instances of `use_transcational_fixtures` to `use_transactional_tests` and “transactional fixtures” to “transactional tests”. I’m deprecating `use_transactional_fixtures=`. So anyone who is explicitly setting this will get a warning telling them to use `use_transactional_tests=` instead. I’m maintaining backwards compatibility—both forms will work. `use_transactional_tests` will check to see if `use_transactional_fixtures` is set and use that, otherwise it will use itself. But because `use_transactional_tests` is a class attribute (created with `class_attribute`) this requires a little bit of hoop jumping. The writer method that `class_attribute` generates defines a new reader method that return the value being set. Which means we can’t set the default of `true` using `use_transactional_tests=` as was done previously because that won’t take into account anyone using `use_transactional_fixtures`. Instead I defined the reader method manually and it checks `use_transactional_fixtures`. If it was set then it should be used, otherwise it should return the default, which is `true`. If someone uses `use_transactional_tests=` then it will overwrite the backwards-compatible method with whatever they set.
-
- 21 2月, 2015 1 次提交
-
-
由 Franky W 提交于
The testing of error messages have been implemented wrongly a few times. This is an attempt to fix it. For example, some of these test should have failed with the new code. The reason they are not failling with the new string is the fact they were not being tested beforehand.
-
- 12 2月, 2015 2 次提交
- 07 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
The same is not true of `define_attribute`, which is meant to be the low level no-magic API that sits underneath. The differences between the two APIs are: - `attribute` - Lazy (the attribute will be defined after the schema has loaded) - Allows either a type object or a symbol - `define_attribute` - Runs immediately (might get trampled by schema loading) - Requires a type object This was the last blocker in terms of public interface requirements originally discussed for this feature back in May. All the implementation blockers have been cleared, so this feature is probably ready for release (pending one more look-over by me).
-
- 01 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
-
- 21 1月, 2015 1 次提交
-
-
由 Vipul A M 提交于
- Added include for the same in ActiveSupport::Test. - Removed occurrences of silence_stream being used elsewhere. - Reordered activesupport testcase requires alphabetically. - Removed require of silence stream from test_case - Moved quietly method to stream helper - Moved capture output to stream helper module and setup requires for the same elsewhere
-
- 20 1月, 2015 1 次提交
-
-
由 Yves Senn 提交于
-
- 10 1月, 2015 1 次提交
-
-
由 Nobuyoshi Nakada 提交于
-
- 04 1月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
`silence_stderr`, `silence_stream`, `capture` and `quietly`.
-
- 14 11月, 2014 1 次提交
-
-
由 Arun Agrawal 提交于
`Computer` class needs to be require See #17217 for more details
-
- 01 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
Fixes #17170
-
由 Sean Griffin 提交于
Sufficiently large integers cause `find` and `find_by` to raise `StatementInvalid` instead of `RecordNotFound` or just returning `nil`. Given that we can't cast to `nil` for `Integer` like we would with junk data for other types, we raise a `RangeError` instead, and rescue in places where it would be highly unexpected to get an exception from casting. Fixes #17380
-
- 02 9月, 2014 1 次提交
-
-
由 Jeremy Kemper 提交于
-
- 29 8月, 2014 3 次提交
-
-
由 Akira Matsuda 提交于
-
由 Akira Matsuda 提交于
-
由 Akira Matsuda 提交于
-
- 20 8月, 2014 1 次提交
-
-
由 Akira Matsuda 提交于
-