- 23 12月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Follow up to #19359 and avoid #22241.
-
- 17 12月, 2015 3 次提交
-
-
由 Abdelkader Boudih 提交于
-
由 Rafael Mendonça França 提交于
This reverts commit 4d06ea9a, reversing changes made to e9d15072. Reason: This will break oracle-enhanced, see https://github.com/rsim/oracle-enhanced/blob/3c42131db82b64ac41645db3affc6e4650289df6/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb#L1254
-
由 Ryuta Kamizono 提交于
-
- 30 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
`pool` in args is unused anymore. And `config` is used in all adapters.
-
- 29 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
-
- 27 11月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
-
- 26 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 24 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
-
- 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
-
- 16 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 09 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
Reported on #21509, how views is treated by `#tables` are differ by each adapters. To fix this different behavior, after Rails 5.0 is released, deprecate `#tables`. And `#table_exists?` would check both tables and views. To make their behavior consistent with `#tables`, after Rails 5.0 is released, deprecate `#table_exists?`.
-
- 08 11月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
The `native_database_types` only used in `TableDefinition` for look up the default `:limit` option. But this is duplicated process with `type_to_sql`. Passing `native_database_types` is not needed.
-
- 03 11月, 2015 1 次提交
-
-
由 Yuki Nishijima 提交于
-
- 31 10月, 2015 1 次提交
-
-
由 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.
-
- 22 10月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
This issue was resolved by #21687 already. But re-add args by #18856. `#tables` extra args was only using by `#table_exists?`. This is for internal API. This commit will remove these extra args again.
-
- 21 10月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Prior to this commit, Rails makes no differentiation between whether a query uses bind parameters, and whether or not we cache that query as a prepared statement. This leads to the cache populating extremely fast in some cases, with the statements never being reused. In particular, the two problematic cases are `where(foo: [1, 2, 3])` and `where("foo = ?", 1)`. In both cases we'll end up quoting the values rather than using a bind param, causing a cache entry for every value ever used in that query. It was noted that we can probably eventually change `where("foo = ?", 1)` to use a bind param, which would resolve that case. Additionally, on PG we can change our generated query to be `WHERE foo = ANY($1)`, and pass an array for the bind param. I hope to accomplish both in the future. For SQLite and MySQL, we still end up preparing the statements anyway, we just don't cache it. The statement will be cleaned up after it is executed. On postgres, we skip the prepare step entirely, as an API is provided to execute with bind params without preparing the statement. I'm not 100% happy on the way this ended up being structured. I was hoping to use a decorator on the visitor, rather than mixing a module into the object, but the way Arel has it's visitor pattern set up makes it very difficult to extend without inheritance. I'd like to remove the duplication from the various places that are extending it, but that'll require a larger restructuring of that initialization logic. I'm going to take another look at the structure of it soon. This changes the signature of one of the adapter's internals, and will require downstream changes from third party adapters. I'm not too worried about this, as worst case they can simply add the parameter and always ignore it, and just keep their previous behavior. Fixes #21992.
-
- 15 10月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Currently `tinyblob` is dumped to `t.binary "tiny_blob", limit: 255`. But `t.binary ... limit: 255` is generating SQL to `varchar(255)`. It is incorrect. This commit fixes this problem.
-
- 13 10月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Current master branch includes many schema dumping improvements. It extract these features to the appropriate files.
-
- 11 10月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
Current master branch includes many schema creation improvements in MySQL. It extract these features to the appropriate file.
-
由 Ryuta Kamizono 提交于
Current master branch includes many schema definition improvements in MySQL. It extract these features to the appropriate file.
-
- 08 10月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
`pk_and_sequence_for` is implemented for PG and MySQL adapters (not implemented for Sqlite3 adapter). But MySQL adapters are not using `pk_and_sequence_for` already.
-
- 04 10月, 2015 1 次提交
-
-
由 Mehmet Emin İNAÇ 提交于
-
- 23 9月, 2015 1 次提交
-
-
由 Yves Senn 提交于
These new methods are used from the Active Record model layer to determine which relations are viable to back a model. These new methods allow us to change `conn.tables` in the future to only return tables and no views. Same for `conn.table_exists?`. The goal is to provide the following introspection methods on the connection: * `tables` * `table_exists?` * `views` * `view_exists?` * `data_sources` (views + tables) * `data_source_exists?` (views + tables)
-
- 20 9月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
`table_exists?` calls `tables` twice when passed `'dbname.tblname'` arg. This change is that `table_exists?` execute only once query always and extra args of `tables` is removed.
-
由 Ryuta Kamizono 提交于
Example: create_table :barcodes, primary_key: ["region", "code"] do |t| t.string :region t.integer :code end
-
- 18 9月, 2015 3 次提交
-
-
由 Ryuta Kamizono 提交于
Currently in schema dumping, `create_table_info` query is called twice for each tables. It means if 100 tables exists, the query is called 200 times. This change is that the query is called once for each tables in schema dumping.
-
由 Ryuta Kamizono 提交于
In the case of using `unsigned` as the type: create_table :foos do |t| t.unsigned_integer :unsigned_integer t.unsigned_bigint :unsigned_bigint t.unsigned_float :unsigned_float t.unsigned_decimal :unsigned_decimal, precision: 10, scale: 2 end
-
由 Ryuta Kamizono 提交于
Example: create_table :foos do |t| t.integer :unsigned_integer, unsigned: true t.bigint :unsigned_bigint, unsigned: true t.float :unsigned_float, unsigned: true t.decimal :unsigned_decimal, unsigned: true, precision: 10, scale: 2 end
-
- 16 9月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
The **(11)** does not affect the storage size of the data type, which for an INT will always be 4 bytes. It affects the **display width**. http://www.tocker.ca/2015/07/02/proposal-to-deprecate-mysql-integer-display-width-and-zerofill.html
-
- 13 9月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 11 9月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 10 9月, 2015 1 次提交
-
-
由 amitkumarsuroliya 提交于
Bumps from `5.6` to `5.7`
-
- 01 9月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 22 8月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Several changes were made in #21110 which I am strongly opposed to. (this is what I get for going on vacation. :trollface:) No type should be introduced into the generic `ActiveRecord::Type` namespace, and *certainly* should not be registered into the registry unconstrained unless it is supported by *all* adapters (which basically means that it was specified in the ANSI SQL standard). I do not think `# :nodoc:` ing the type is sufficient, as it still makes the code of Rails itself very unclear as to what the role of that class is. While I would argue that this shouldn't even be a super class, and that MySql and PG's JSON types are only superficially duplicated (they might look the same but will change for different reasons in the future). However, I don't feel strongly enough about it as a point of contention (and the biggest cost of harming the blameability has already occured), so I simply moved the superclass into a namespace where its role is absolutely clear. After this change, `attribute :foo, :json` will once again work with MySQL and PG, but not with Sqlite3 or any third party adapters. Unresolved questions -------------------- The types that and adapter publishes (at least those are unique to that adapter, and not adding additional behavior like `MysqlString` should probably be part of the adapter's public API. Should we standardize the namespace for these, and document them?
-
- 21 8月, 2015 1 次提交
-
-
由 Yasuo Honda 提交于
-