Forgot the preceding space, so that line should really be:
create_sql << " #{options[:column_options]}" if
options.has_key?(:column_options)
That way the outputted sql will be same as was before, even if not
specifying that option.
On Wednesday, November 28, 2012 12:45:35 PM UTC-5, Gary Weaver wrote:
>
> So proposal would be in
> activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
>
> You would add :column_options support, like:
>
> def create_table(table_name, options = {})
> td = table_definition
> td.primary_key(options[:primary_key] ||
> Base.get_primary_key(table_name.to_s.singularize)) unless options[:id] ==
> false
>
> yield td if block_given?
>
> if options[:force] && table_exists?(table_name)
> drop_table(table_name, options)
> end
>
> create_sql = "CREATE#{' TEMPORARY' if options[:temporary]} TABLE "
> create_sql << "#{quote_table_name(table_name)} ("
> create_sql << td.to_sql
> create_sql << "#{options[:column_options]}"
> create_sql << ") #{options[:options]}"
> execute create_sql
> td.indexes.each_pair { |c,o| add_index table_name, c, o }
> end
>
> Not sure if would want to add similar option in other places to be
> consistent, though...
>
> On Wednesday, November 28, 2012 12:31:37 PM UTC-5, Gary Weaver wrote:
>>
>> For the create_table though, I'm not sure there is a way to specify
>> options that go inside the parenthesis.
>>
>> For example this fails because it puts deferrable on the outside of the
>> parenths:
>>
>> create_table(:test3, :options => 'deferrable') do |t|
>> t.string :some_id
>> end
>>
>> $ rake db:migrate
>> == TestMigration: migrating
>> ==================================================
>> -- create_table(:test3, {:options=>"deferrable"})
>> rake aborted!
>> An error has occurred, this and all later migrations canceled:
>>
>> PG::Error: ERROR: syntax error at or near "deferrable"
>> LINE 1: ...al primary key, "some_id" character varying(255)) deferrable
>>
>> Maybe there should be a concept like column_options: 'deferrable'
>>
>> create_table(:test3, :column_options => 'deferrable') do |t|
>> t.string :some_id
>> end
>>
>> ?
>>
>> On Wednesday, November 28, 2012 11:55:57 AM UTC-5, Gary Weaver wrote:
>>>
>>> afaik using foreigner is still the recommended way to handle fkeys in
>>> Rails. Here is the pull request in foreigner where they discuss deferrable
>>> a few years ago: https://github.com/matthuhiggins/foreigner/pull/32
>>>
>>> Using Foreigner v0.9.1 or later and using structure.sql vs. schema.rb
>>> then can specify :options in foreigner's add_foreign_key, e.g.
>>>
>>> add_foreign_key(:employees, :companies, :options => 'deferrable')
>>>
>>> Related rails ticket which had no follow through, mostly related to
>>> deferred use in fixtures: https://github.com/rails/rails/issues/5523
>>>
>>> Unrelated, but for those interested, sequel just added support for
>>> deferrable constraints in pg:
>>> https://github.com/jeremyevans/sequel/pull/583
>>>
>>> Hope that helps.
>>>
>>> On Thursday, November 22, 2012 9:36:18 AM UTC-5, Rodrigo Rosenfeld Rosas
>>> wrote:
>>>>
>>>> Although I don't use ActiveRecord as an ORM, I do use its migrations
>>>> framework for evolving my database schema through standalone_migrations.
>>>>
>>>> But I'm finding the current DSL limited with regards to deferrable
>>>> constraints support.
>>>>
>>>> Let me demonstrate with a common use-case, like trees implementation,
>>>> with SQL written for PostgreSQL:
>>>>
>>>> create table tree(parent_id integer not null, position integer not
>>>> null, unique(parent_id, position));
>>>> insert into tree(parent_id, position) select generate_series(1, 3), 1;
>>>> insert into tree(parent_id, position) select generate_series(1, 3), 2;
>>>>
>>>> update tree set position = position + 1;
>>>>
>>>> ERROR: duplicate key value violates unique constraint
>>>> "tree_parent_id_position_key"
>>>>
>>>> In PostgreSQL the constraint check is performed during the UPDATE, so
>>>> its success will depend on what order PG will try to update the "position"
>>>> field.
>>>>
>>>> Since we want PG to defer the constraint check to the end of the UPDATE
>>>> statement (it is also possible to specify constraints to be check on
>>>> transaction commit, but I'll keep this short) we must create this "tree"
>>>> table in PG like this:
>>>>
>>>> create table tree(parent_id integer not null, position integer not
>>>> null, unique(parent_id, position) *deferrable*);
>>>>
>>>> But there is no DSL support in migrations to tell the database to use a
>>>> deferrable constraint when supported by the database.
>>>>
>>>> Also, I believe that deferrable should be the default and one should
>>>> specify "deferrable: false" if this is not desired in case add_index would
>>>> support a "deferrable" option. In such case, it should generate a
>>>> statement
>>>> like:
>>>>
>>>> alter table :table_name add constraint :constraint_name unique
>>>> (parent_id, position) deferrable
>>>>
>>>> Another option would be to introduce some "add_constraint" DSL to
>>>> Migrations. Anyway, there should be some way of stating this deferrable
>>>> information in schema.rb.
>>>>
>>>> Each approach would be fine to me as long as I don't need to do it
>>>> myself using PG-specific SQL with "execute" method.
>>>>
>>>> Thanks for considering,
>>>> Rodrigo.
>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/zPmouqjfLx4J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
