This was there due historical reasons since 7dc4581 to give the user the possibility to create unique indexes passing "UNIQUE" as the third argument
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
The RFC indicates that username and passwords may be encoded. http://tools.ietf.org/html/rfc2396#section-3.2.2 Found this trying to use the mysql://username:password@host:port/db and having special characters in the password which needed to be URI encoded.
In the end I think the pain of implementing this seamlessly was not worth the gain provided. The intention was that it would allow plain ruby objects that might not live in your main application to be subclassed and have persistence mixed in. But I've decided that the benefit of doing that is not worth the amount of complexity that the implementation introduced.
In non-strict mode it is '', but if someone is in strict mode then we should honour the strict semantics. Also, this removes the need for a completely horrible hack in dirty.rb. Closes #7780
According to postgreSQL documentation: (http://www.postgresql.org/docs/8.2/static/catalog-pg-attrdef.html) we should not be using 'adsrc' field because this field is unaware of outside changes that could affect the way that default values are represented. Thus, I changed the queries to use "pg_get_expr(adbin, adrelid)" instead of the historical "adsrc" field.
PostgreSQL adapter properly parses default values when using multiple schemas and domains. When using domains across schemas, PostgresSQL prefixes the type of the default value with the name of the schema where that type (or domain) is. For example, this query: ``` SELECT a.attname, d.adsrc FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = "defaults"'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum; ``` could return something like "'<default_value>'::pg_catalog.text" or "(''<default_value>'::pg_catalog.text)::text" for the text columns with defaults. I modified the regexp used to parse this value so that it ignores anything between ':: and \b(?:character varying|bpchar|text), and it allows to have optional parens like in the above second example.
When inserting new records, only the fields which have been changed from the defaults will actually be included in the INSERT statement. The other fields will be populated by the database. This is more efficient, and also means that it will be safe to remove database columns without getting subsequent errors in running app processes (so long as the code in those processes doesn't contain any references to the removed column).
If your database supports setting the isolation level for a transaction, you can set it like so: Post.transaction(isolation: :serializable) do # ... end Valid isolation levels are: * `:read_uncommitted` * `:read_committed` * `:repeatable_read` * `:serializable` You should consult the documentation for your database to understand the semantics of these different levels: * http://www.postgresql.org/docs/9.1/static/transaction-iso.html * https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html An `ActiveRecord::TransactionIsolationError` will be raised if: * The adapter does not support setting the isolation level * You are joining an existing open transaction * You are creating a nested (savepoint) transaction The mysql, mysql2 and postgresql adapters support setting the transaction isolation level. However, support is disabled for mysql versions below 5, because they are affected by a bug (http://bugs.mysql.com/bug.php?id=39170) which means the isolation level gets persisted outside the transaction.