- 18 4月, 2016 2 次提交
-
-
由 Tomasz Stachewicz 提交于
[ci skip] Update ActiveRecord associations documentation to avoid confusion with :validate option. Caused by #24532.
-
由 bogdanvlviv 提交于
-
- 17 4月, 2016 1 次提交
-
-
由 Alex Handley 提交于
- Add link for finding the addional options for index. - Add example for unique index as this is a common requirement. - Add link in guide for index options.
-
- 16 4月, 2016 1 次提交
-
-
由 Andrey Novikov 提交于
Comments are specified in migrations, stored in database itself (in its schema), and dumped into db/schema.rb file. This allows to generate good documentation and explain columns and tables' purpose to everyone from new developers to database administrators. For PostgreSQL and MySQL only. SQLite does not support comments at the moment. See docs for PostgreSQL: http://www.postgresql.org/docs/current/static/sql-comment.html See docs for MySQL: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
-
- 15 4月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
Follow up to #24542. In MySQL and PostgreSQL, a time column value is saved as ignored the date part of it. But in SQLite3, a time column value is saved as a string. We should keep previous quoting behavior in sqlite3 adapter. ``` sqlite> CREATE TABLE "foos" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "start" time(0), "finish" time(4)); sqlite> INSERT INTO "foos" ("start", "finish") VALUES ('2000-01-01 12:30:00', '2000-01-01 12:30:00.999900'); sqlite> SELECT "foos".* FROM "foos"; 1|2000-01-01 12:30:00|2000-01-01 12:30:00.999900 sqlite> SELECT "foos".* FROM "foos" WHERE "foos"."start" = '2000-01-01 12:30:00' LIMIT 1; 1|2000-01-01 12:30:00|2000-01-01 12:30:00.999900 sqlite> SELECT "foos".* FROM "foos" WHERE "foos"."start" = '12:30:00' LIMIT 1; sqlite> ```
-
- 14 4月, 2016 3 次提交
-
-
由 Ryuta Kamizono 提交于
Context #24522. TIME column on MariaDB doesn't ignore the date part of the string when it coerces to time. ``` root@localhost [test] > CREATE TABLE `foos` (`id` int AUTO_INCREMENT PRIMARY KEY, `start` time(0), `finish` time(4)) ENGINE=InnoDB; Query OK, 0 rows affected (0.02 sec) root@localhost [test] > INSERT INTO `foos` (`start`, `finish`) VALUES ('2000-01-01 12:30:00', '2000-01-01 12:30:00.999900'); Query OK, 1 row affected, 2 warnings (0.00 sec) Note (Code 1265): Data truncated for column 'start' at row 1 Note (Code 1265): Data truncated for column 'finish' at row 1 root@localhost [test] > SELECT `foos`.* FROM `foos`; +----+----------+---------------+ | id | start | finish | +----+----------+---------------+ | 1 | 12:30:00 | 12:30:00.9999 | +----+----------+---------------+ 1 row in set (0.00 sec) root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '2000-01-01 12:30:00' LIMIT 1; Empty set (0.00 sec) root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '12:30:00' LIMIT 1; +----+----------+---------------+ | id | start | finish | +----+----------+---------------+ | 1 | 12:30:00 | 12:30:00.9999 | +----+----------+---------------+ 1 row in set (0.00 sec) ```
-
由 Vipul A M 提交于
- Specify we want to run on latest stable ruby for mariadb - change in runs of builds Make mariadb? method publicly available
-
由 Sean Griffin 提交于
Previously we were assuming that the only valid types for encoding were arrays and hashes. However, any JSON primitive is an accepted value by both PG and MySQL. This does involve a minor breaking change in the handling of `default` in the schema dumper. This is easily worked around, as passing a hash/array literal would have worked fine in previous versions of Rails. However, because of this, I will not be backporting this to 4.2 or earlier. Fixes #24234
-
- 13 4月, 2016 2 次提交
-
-
由 Vipul A M 提交于
Reason: - Its not publicly used method. - Exposing it makes an assumption that other adapters support it based on its usage - ActiveRecord::Base.connection.version [ci skip]
-
由 Sean Griffin 提交于
In 04ac5655 I assumed that we would never want to pass the "table_name.column_name" form to where with a symbol. However, in Ruby 2.2 and later, you can quote symbols using the new hash syntax, so it's a semi-reasonable thing to do if we want to support the dot notation (which I'd rather deprecate, but that would be too painful of a migration). Instead we've changed the definition of "this is a table name with a dot" to when the value associated is a hash. It would make very little sense to write `where("table_name.column_name": { foo: :bar })` in any scenario (other than equality for a JSON column which we don't support through `where` in this way). Close #24514.
-
- 12 4月, 2016 1 次提交
-
-
由 Vipul A M 提交于
- we are ending sentences properly - fixing of space issues - fixed continuity issues in some sentences. Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 . This change reverts making sure we add '.' at end of deprecation sentences. This is to keep sentences within Rails itself consistent and with a '.' at the end.
-
- 11 4月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
Rake includes (an extended version of) FileUtils in tasks. It is more idiomatic that they use this provided interface.
-
- 10 4月, 2016 2 次提交
-
-
由 Prathamesh Sonpatki 提交于
-
由 Prathamesh Sonpatki 提交于
- Check for protected environments while running `db:structure:load` similar to how `db:schema:load` behaves. - Followup of https://github.com/rails/rails/pull/24399.
-
- 09 4月, 2016 1 次提交
-
-
由 Jeremy Daer 提交于
We support microsecond datetime precision for MySQL 5.6.4+. MariaDB has supported it since 5.3.0, but even 10.x versions return a compatible version string like `5.5.5-10.1.8-MariaDB-log` which we parse as 5.5.5, before MySQL supported microsecond precision. Specialize our version check to account for MariaDB to fix.
-
- 06 4月, 2016 3 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ladislav Smola 提交于
* Fix undefined method `owners' for NullPreloader:Class Fixing undefined method `owners' for ActiveRecord::Associations::Preloader::NullPreloader:Class * Use Ruby 1.9 hash format Use Ruby 1.9 hash format #24192 [Rafael Mendonça França + Ladislav Smola]
-
由 Harsimran Singh Maan 提交于
The hard-coded back-ticks made it hard to use a different char for quoting db fields. This checkin replaces it with quote_table_name.
-
- 05 4月, 2016 4 次提交
-
-
由 Ryuta Kamizono 提交于
Move `quoted_date`, `quote_string` and `quote_table_name_for_assignment` methods to `Quoting` module
-
由 Ryuta Kamizono 提交于
-
由 yui-knk 提交于
Because we define `QUOTED_TRUE` as `"1"` and `QUOTED_FALSE` as `"0"`. And add test cases to ensure this commit does not break current behavior even if the value of `attributes_before_type_cast` is false.
-
由 Matthew Draper 提交于
Also, make sure to call the +complete+ hooks if +run+ fails.
-
- 02 4月, 2016 1 次提交
-
-
由 Jerry Cheung 提交于
Follow up to https://github.com/rails/rails/pull/22967 to protect against loading a schema on accident in production. cc @schneems
-
- 01 4月, 2016 4 次提交
-
-
由 Sean Griffin 提交于
This reverts commit 7b82e1c7. This would have removed the ability to reference a schema when using PG
-
由 Sean Griffin 提交于
When prepared statements are enabled, the statement cache caches the SQL directly, including the bind parameters. If a similar query is run later with prepared statements disabled, we need to use a separate cache instead of trying to share the same one. Fixes #24351
-
由 Sean Griffin 提交于
Dots have special meaning in most backends (e.g. everything except SQLite3), as well as most methods that work with table or column names. This isn't something that we ever explicitly supported, but there's at least one case of somebody using this (see #24367), so we'll go through a deprecation cycle as normal.
-
由 Sean Griffin 提交于
This issue occured because associations now call `where` directly, and a dot in the key name for `where` means nested tables. For this fix, we now pass the table name as a symbol, and do not attempt to expand symbols containing a dot. This is a temporary fix. I do not think we should support table names containing a dot, as it has a special meaning in most backends, as well as most APIs that involve table names. This commit does not include a test, as I am going to deprecate table names containing dots in the following commit. Fixes #24367
-
- 31 3月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 30 3月, 2016 3 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Dennis Ushakov 提交于
-
由 Ryuta Kamizono 提交于
-
- 29 3月, 2016 1 次提交
-
-
由 Kenta 提交于
-
- 27 3月, 2016 2 次提交
-
-
由 Sourav Moitra 提交于
s removed objects added
-
由 Bogdan 提交于
Fix description for method ActiveRecord::ConnectionAdapters::SchemaStatements#add_timestamps [ci skip]
-
- 26 3月, 2016 2 次提交
-
-
由 Bogdan 提交于
-
由 Santosh Wadghule 提交于
-
- 25 3月, 2016 4 次提交
-
-
由 Rafael Mendonça França 提交于
This reverts commit 43ccebc1. This is not fixing the configuration problem since we are assigning to the ActiveRecord::Base not the configuration. See #24303.
-
由 Sean Griffin 提交于
When a proc is given as a default value, the form builder ends up displaying `Proc#to_s` when the default is used. That's because we didn't handle the proc until type casting. This issue technically can occur any time that a proc is the value before type casting, but in reality the only place that will occur is when a proc default is provided through the attributes API, so the best place to handle this edge case is there. I've opted to memoize instead of just moving the `Proc#call` up, as this made me realize that it could potentially interact very poorly with dirty checking. The code here is a little redundant, but I don't want to rely on how `value_before_type_cast` is implemented in the super class, even if it's just an `attr_reader`. Fixes #24249 Close #24306
-
由 Arthur Neves 提交于
`prefetch_primary_key?` and `next_sequence_value` methods live in the connection level at the moment, that make sense when you are generating the sequence from the database, in the same connection. Which is the use case today at the Oracle and Postgres adapters. However if you have an service that generates IDs, that has nothing to do with the database connection, and should not be fetched from there. Another use case, is if you want to use another connection to fetch IDs, that would not be possible with the current implementation, however when we move those methods to the model level, you can use a new connection there. Also this makes easier for gems to add behavior on those methods.
-
由 Chris Arcand 提交于
Without clearing the caches afterward, removals done in migrations would not be reflected in a separate task in the same process. That is, given a table with a migration to remove a column, the schema cache would still reflect that a table has that in something such as the 'db:seed' task: `rake db:migrate db:seed` (A common thing to do in a script for a project ala `bin/setup`) vs `rake db:migrate && rake db:seed` (Two processes) The first would not reflect that the column was removed. The second would (cache reset).
-