Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Default Primary Keys to BIGINT #26266

Merged
merged 2 commits into from Dec 5, 2016
Merged

Change Default Primary Keys to BIGINT #26266

merged 2 commits into from Dec 5, 2016

Conversation

@jmccartie
Copy link
Contributor

@jmccartie jmccartie commented Aug 24, 2016

Friends don't let friends use INT as a primary key.

— Schneems (@schneems) May 13, 2016

Summary

Per a conversation with @sgrif: changes default primary keys from Integer to BIGINT for both Postgresql and MySQL. Leaves behavior alone for SQLite since this database does not provide support for BIGINT primary keys.

Other Information

For obvious reasons, this also requires foreign keys to change from integer to bigints. As a result the test suite's schema.rb has been change in the necessary places.

I'll squash and add a CHANGELOG entry once the rest looks ok...

@rails-bot
Copy link

@rails-bot rails-bot commented Aug 24, 2016

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

@sgrif sgrif assigned sgrif and unassigned kaspth Aug 24, 2016
@sgrif
Copy link
Contributor

@sgrif sgrif commented Aug 24, 2016

We'll need to make sure that migrations written against 5.0 and later don't have the type of their primary key changed.

@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 24, 2016

@sgrif Can you recommend a best-practice for ensuring that? Have we done something like that in the past that I can learn from?

@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 24, 2016

@sgrif Thanks.

@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch Aug 24, 2016
@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 24, 2016

@sgrif So override the necessary methods inside class V5_0 ?

@rafaelfranca
Copy link
Member

@rafaelfranca rafaelfranca commented Aug 24, 2016

This is a dup of #24962. While this implementation may be more complete it is really a bad OSS etiquette to finish other people PR without given them a chance to finish it or proper credits.

My recommendation:

  1. pull #24962 commits in this PR.
  2. Work on top of that commits
@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 24, 2016

@rafaelfranca Ah - thanks for showing me that. I searched for open PR's, but that didn't turn up for me.

I work at Heroku with @rwz, so I'll cycle around with him and see if we can tag team this.

@rafaelfranca
Copy link
Member

@rafaelfranca rafaelfranca commented Aug 24, 2016

👍

@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch Aug 24, 2016
@jmccartie jmccartie closed this Aug 24, 2016
@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch to 0d2f79b Aug 24, 2016
@jmccartie jmccartie reopened this Aug 24, 2016
@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch Aug 24, 2016
@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 24, 2016

I've now entered into the 3rd layer of git rebase hell...

@rafaelfranca
Copy link
Member

@rafaelfranca rafaelfranca commented Aug 24, 2016

I've now entered into the 3rd layer of git rebase hell...

lol. This is really tough.

@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch Aug 24, 2016
@kaspth
Copy link
Member

@kaspth kaspth commented Aug 24, 2016

r? @sgrif

@schneems
Copy link
Member

@schneems schneems commented Aug 25, 2016

Looks like tests are passing now

@sgrif
sgrif reviewed Aug 25, 2016
View changes
activerecord/lib/active_record/migration/compatibility.rb Outdated
# Since version 5.1 Postgres adapter uses bigserial type for primary
# keys by default. This compat layer makes old migrations utilize
# serial type instead, the way it used to work before 5.1
if connection.adapter_name == "PostgreSQL"

This comment has been minimized.

@sgrif

sgrif Aug 25, 2016
Contributor

This needs to handle MySQL as well. Is it possible for us to implement this in an adapter agnostic way?

This comment has been minimized.

@jmccartie

jmccartie Aug 25, 2016
Author Contributor

Yeah, I can make that change.

On Thu, Aug 25, 2016 at 10:13 AM, Sean Griffin notifications@github.com
wrote:

In activerecord/lib/active_record/migration/compatibility.rb
#26266 (comment):

@@ -103,6 +103,16 @@ def index_name_for_remove(table_name, options = {})
end

   class V5_0 < V5_1
  •    def create_table(table_name, options = {})
    
  •      # Since version 5.1 Postgres adapter uses bigserial type for primary
    
  •      # keys by default. This compat layer makes old migrations utilize
    
  •      # serial type instead, the way it used to work before 5.1
    
  •      if connection.adapter_name == "PostgreSQL"
    

This needs to handle MySQL as well. Is it possible for us to implement
this in an adapter agnostic way?


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/rails/rails/pull/26266/files/de485a4379a265218f1bbea900c08f45e39a93fd#r76285358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIJEYj45MhqMMLNBPIkwwMhoRSdHCBuks5qjc1DgaJpZM4JrgwZ
.

@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 25, 2016

@sgrif Added a test for MySQL compatibility. The logic still queues off the adapter name, though. We could move that logic into a default on each adapter, but then we have some sort of "legacy_primary_key" method on the adapter itself, which I liked much less than the ternary.

Thoughts?

@sgrif
Copy link
Contributor

@sgrif sgrif commented Aug 26, 2016

Can we just make the PG adapter do the right thing when the PK type is integer?

@jmccartie
Copy link
Contributor Author

@jmccartie jmccartie commented Aug 26, 2016

@sgrif I'm not sure. Both adapters need the logic since we need to ensure MySQL uses integer (and not bigint) and Postgresql uses serial (and not bigserial)

@sgrif
Copy link
Contributor

@sgrif sgrif commented Aug 26, 2016

How about just :integer?

On Thu, Aug 25, 2016 at 11:04 PM Jon McCartie notifications@github.com
wrote:

@sgrif https://github.com/sgrif Something like this?

options[:id] ||= connection.class::LEGACY_PK_TYPE


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#26266 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdWK2-R2Rj-aRqV77WLaJaf0AC5MeBYks5qjlfYgaJpZM4JrgwZ
.

@jmccartie jmccartie force-pushed the jmccartie:jm/bigint branch Aug 26, 2016
jrafanie added a commit to jrafanie/manageiq-schema that referenced this pull request Mar 26, 2019
Rails 5.1 changed the default primary key type from integer to bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for versions less than 5.1 to
default to integer if not provided.  Since we want our default to be bigint/bigserial for those old
migrations, we need to prepend our module on the migration class for old migrations
jrafanie added a commit to jrafanie/manageiq-schema that referenced this pull request Apr 1, 2019
Rails 5.1 changed the default primary key type from integer to bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for versions less than 5.1 to
default to integer if not provided.  Since we want our default to be bigint/bigserial for those old
migrations, we need to prepend our module on the migration class for old migrations
jrafanie added a commit to jrafanie/manageiq-schema that referenced this pull request Apr 5, 2019
Rails 5.1 changed the default primary key type from integer to bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for versions less than 5.1 to
default to integer if not provided.  Since we want our default to be bigint/bigserial for those old
migrations, we need to prepend our module on the migration class for old migrations
jrafanie added a commit to jrafanie/manageiq-schema that referenced this pull request Apr 9, 2019
Rails 5.1 changed the default primary key type from integer to bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for versions less than 5.1 to
default to integer if not provided.  Since we want our default to be bigint/bigserial for those old
migrations, we need to prepend our module on the migration class for old migrations
jrafanie added a commit to jrafanie/manageiq-schema that referenced this pull request Apr 10, 2019
Rails 5.1 changed the default primary key type from integer to bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for versions less than 5.1 to
default to integer if not provided.  Since we want our default to be bigint/bigserial for those old
migrations, we need to prepend our module on the migration class for old migrations
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 11, 2019
Rails 5.1 changed the default primary key type from integer to
bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for
versions less than 5.1 to default to integer if not provided.  Since
we want our default to be bigint/bigserial for those old migrations,
we need to prepend our module on the migration class for old migrations.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 11, 2019
Rails 5.1 changed the default primary key type from integer to
bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for
migration versions less than 5.1 to default to integer if not provided.
Since we want our default to be bigint/bigserial for those old migrations,
we need to prepend our module on the migration class for 5.0 migrations.
Note: 4.2, 5.1+ migrations all derive from the 5.0 version, so we only
need to patch it once, at the 5.0 migration compatibility layer.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 11, 2019
Rails 5.1 changed the default primary key type from integer to
bigint/bigserial in:

rails/rails#26266

With this change, they modified the default compatibility layer for
migration versions less than 5.1 to default to integer if not provided.
Since we want our default to be bigint/bigserial for those old migrations,
we need to prepend our module on the migration class when Rails tries to
find it in the compatilibity stack.

Also suppress messages for migrations in specs.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 23, 2019
Rails 5.1+ changed the default primary key type from integer to bigserial in:
rails/rails#26266

With this change, they modified the default compatibility layer for migration
versions less than 5.1 to default to integer if not provided.  Since we need
bigserial ids for region support, we need 4.2 and 5.0 versioned migrations
to also use bigserial id columns unless they explicitly say id => false
for tables without id columns.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 26, 2019
Rails 5.1+ changed the default primary key type from integer to bigserial in:
rails/rails#26266

With this change, they modified the default compatibility layer for migration
versions less than 5.1 to default to integer if not provided.  Since we need
bigserial ids for region support, we need 4.2 and 5.0 versioned migrations
to also use bigserial id columns unless they explicitly say id => false
for tables without id columns.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 26, 2019
Rails 5.1+ changed the default primary key type from integer to bigserial in:
rails/rails#26266

With this change, they modified the default compatibility layer for migration
versions less than 5.1 to default to integer if not provided.  Since we need
bigserial ids for region support, we need 4.2 and 5.0 versioned migrations
to also use bigserial id columns unless they explicitly say id => false
for tables without id columns.
jrafanie added a commit to jrafanie/activerecord-id_regions that referenced this pull request Apr 29, 2019
Rails 5.1+ changed the default primary key type from integer to bigserial in:
rails/rails#26266

With this change, they modified the default compatibility layer for migration
versions less than 5.1 to default to integer if not provided.  Since we need
bigserial ids for region support, we need 4.2 and 5.0 versioned migrations
to also use bigserial id columns unless they explicitly say id => false
for tables without id columns.
rbns added a commit to rbns/the-idb that referenced this pull request Jun 10, 2020
rails 5.1 defaults to bigint rowids [1]. this lets foreign table
constraints fail, as the types of the compared columns doesn't
match anymore. int in the referencing column, bigint in the
referred column.

this patches schema.rb to use int id columns for the tables. [2]

[1] rails/rails#26266

[2] https://ridingtheclutch.com/post/160099545985/rails-51-new-default-bigint-primary-key-sort-of
rbns added a commit to rbns/the-idb that referenced this pull request Jun 10, 2020
rails 5.1 defaults to bigint rowids [1]. this lets foreign table
constraints fail, as the types of the compared columns doesn't
match anymore. int in the referencing column, bigint in the
referred column.

this patches schema.rb to use int id columns for the tables. [2]

[1] rails/rails#26266

[2] https://ridingtheclutch.com/post/160099545985/rails-51-new-default-bigint-primary-key-sort-of
rbns added a commit to rbns/the-idb that referenced this pull request Jun 10, 2020
rails 5.1 defaults to bigint rowids [1]. this lets foreign table
constraints fail, as the types of the compared columns doesn't
match anymore. int in the referencing column, bigint in the
referred column.

this patches schema.rb to use int id columns for the tables. [2]

[1] rails/rails#26266

[2] https://ridingtheclutch.com/post/160099545985/rails-51-new-default-bigint-primary-key-sort-of
Hamms added a commit to code-dot-org/code-dot-org that referenced this pull request Oct 21, 2020
The default type was changed in rails/rails#26266, so to preserve existing functionality we now have to explicitly say that our current table deviate from the default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.