blocks|key|1453203|text|在迁移中似乎没有add_column方法的位置选项。但是迁移支持执行文字SQL。我不是Rails开发人员，但类似于以下内容：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1453204|class+AddColumnAfterOtherColumn+<+ActiveRecord::Migration
++def+self.up
++++execute+"ALTER+TABLE+table_name+ADD+COLUMN+column_name+INTEGER+
++++++AFTER+other_column"
++end

++def+self.down
++++remove_column+:table_name,+:column_name
++end
end|code-block|syntax|javascript|1453205|entityMap^0|8|A|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

There does not seem to be a position option for the <code>add_column</code> method in migrations. But migrations support executing literal SQL. I'm no Rails developer, but something like the following:

<pre><code>class AddColumnAfterOtherColumn &lt; ActiveRecord::Migration
 def self.up
 execute "ALTER TABLE table_name ADD COLUMN column_name INTEGER 
 AFTER other_column"
 end

 def self.down
 remove_column :table_name, :column_name
 end
end
</code></pre>

blocks|key|1453257|text|在Rails中无法指定列的位置。事实上，我认为创建列的顺序与它们在迁移中的命名顺序是巧合的(因此不值得依赖)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1453258|表中列的顺序几乎是相关的，也应该是相关的:给出的常见“原因”是在执行"SELECT+*“时能够看到特定的子集，但这确实不是一个很好的原因。|1453259|任何其他原因可能是设计的味道，但我很想知道我错了的一个有效原因！|1453260|在某些平台上，通过将最高概率为NULL的列放到末尾(因为DMBS不会使用任何磁盘空间来“拖尾”NULL值，但我认为您必须运行在20世纪80年代的硬件上才能注意到)，可以获得(极小的)空间和性能节省。|1453261|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There is no way within Rails to specify the position of a column. In fact, I think it's only coincidental (and therefore not to be relied on) that columns are created in the order they are named in a migration.

The order of columns within a table is almost relevant and should be so: the common "reason" given is to be able to see a particular subset when executing a "SELECT *", but that's really not a good reason.

Any other reason is probably a design smell, but I'd love to know a valid reason why I'm wrong!

On some platforms, there is a (miniscule) space and performance saving to be obtained by putting the columns with the highest probability of being NULL to the end (because the DMBS will not use any disk space for "trailing" NULL values, but I think you'd have to be running on 1980's hardware to notice.

blocks|key|1668345|text|我创建了一个补丁，将此附加功能添加到ActiveRecord+Mysql适配器中。它适用于master和2-3-稳定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1668346|https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations|offset|length|1668347|它可能是特定于mysql的，但它不会降低迁移的可移植性(其他适配器会忽略额外的定位选项)。|1668348|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|3B|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

I created a patch that adds this additional functionality to the ActiveRecord Mysql adapter. It works for master and 2-3-stable.

<a href="https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations" rel="noreferrer">https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations</a>

It might be mysql specific, but it doesn't make your migrations any less portable (other adapters would just ignore the extra positioning options).

blocks|key|1453327|text|在Rails+2.3.6%2B中，现在可以通过传递:after参数实现这一点|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1453328|https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations|offset|length|1453329|对于那些没有意识到拥有这个特性的好处的人来说:您是否从不在ORM之外查看您的数据库？如果我在任何类型的UI中查看，我喜欢将外键、状态列、标志等所有内容组合在一起。这不会影响应用程序，但肯定会加快我检查数据的速度。|1453330|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|3B|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

This is now possible in Rails 2.3.6+ by passing the :after parameter

<a href="https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations" rel="noreferrer">https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations</a>

To everyone that doesn't see the advantage in having this feature: do you never look at your database outside of the ORM? If I'm viewing in any sort of UI, I like having things like foreign keys, status columns, flags, etc, all grouped together. This doesn't impact the application, but definitely speeds up my ability to review data.

If I'm adding a column via MySQL, I can specify where in the table that column will be using the AFTER modifier. But if I do the add_column via a Rails migration, the column will be created at the end of the table.

Is there any functionality for rails migrations to specify the position of an added column?

In a Rails Migration (MySQL), can you specify what position a new column should be?

数据库

MySQL

如果我通过MySQL添加一个列，我可以指定该列将在表中的什么位置使用AFTER修饰符。但是，如果我通过Rails迁移执行add_column，则将在表的末尾创建该列。rails迁移是否有指定添加列的位置的功能？

问在Rails迁移(MySQL)中，您能指定新列的位置吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Rails迁移(MySQL)中，您能指定新列的位置吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Rails迁移(MySQL)中，您能指定新列的位置吗？
EN