Rails default to a defined value
1
Hello I was wondering what the correct way to a defined default value as in
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: "Your value"
end
end
but instead of "Your Value" it was @yourvalue which is stored in a @settings model
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: @settings.yourvalue
end
end
class CreateSettings < ActiveRecord::Migration[5.2]
def change
create_table
t.string :yourvalue
t.timestamps
end
end
end
@yourvalue would be defined and updated by a user
ruby-on-rails postgresql
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
|
show 1 more comment
1
Hello I was wondering what the correct way to a defined default value as in
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: "Your value"
end
end
but instead of "Your Value" it was @yourvalue which is stored in a @settings model
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: @settings.yourvalue
end
end
class CreateSettings < ActiveRecord::Migration[5.2]
def change
create_table
t.string :yourvalue
t.timestamps
end
end
end
@yourvalue would be defined and updated by a user
ruby-on-rails postgresql
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
@settingsis a AR model row?
– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14
|
show 1 more comment
1
1
1
Hello I was wondering what the correct way to a defined default value as in
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: "Your value"
end
end
but instead of "Your Value" it was @yourvalue which is stored in a @settings model
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: @settings.yourvalue
end
end
class CreateSettings < ActiveRecord::Migration[5.2]
def change
create_table
t.string :yourvalue
t.timestamps
end
end
end
@yourvalue would be defined and updated by a user
ruby-on-rails postgresql
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
Hello I was wondering what the correct way to a defined default value as in
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: "Your value"
end
end
but instead of "Your Value" it was @yourvalue which is stored in a @settings model
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: @settings.yourvalue
end
end
class CreateSettings < ActiveRecord::Migration[5.2]
def change
create_table
t.string :yourvalue
t.timestamps
end
end
end
@yourvalue would be defined and updated by a user
ruby-on-rails postgresql
ruby-on-rails postgresql
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
edited Nov 21 '18 at 22:51
Joe Bloggs
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
asked Nov 21 '18 at 22:43
Joe BloggsJoe Bloggs
201111
201111
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
@settingsis a AR model row?
– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14
|
show 1 more comment
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
@settingsis a AR model row?
– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
@settings is a AR model row?– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
@settings is a AR model row?– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14
|
show 1 more comment
2 Answers
2
active
oldest
votes
1
Migrations are normal Ruby classes. You can write Rails code within them. Eg. you can access your models.
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :string, default: Setting.find(1).yourvalue
end
end
Replace Setting.find(1) with whatever logic you need to filter.
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrapSetting.find(1)to check if the records exists before doing the change. else do a no-op migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
add a comment |
1
I would set it on the model so your migrations remain non-reliant on previous states of the data therein.
class TableName < ApplicationRecord
before_create :add_defaults
# whatever
private
def add_defaults
self.column_name = Setting.find(1).default_value unless column_name
end
end
This way you won't be invoking ActiveRecord from the migration, and your app will still work if you deploy it somewhere and run the migrations before adding a Setting record. You'll likely need a fully-migrated database before adding any data.
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421461%2frails-default-to-a-defined-value%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
Migrations are normal Ruby classes. You can write Rails code within them. Eg. you can access your models.
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :string, default: Setting.find(1).yourvalue
end
end
Replace Setting.find(1) with whatever logic you need to filter.
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrapSetting.find(1)to check if the records exists before doing the change. else do a no-op migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
add a comment |
1
Migrations are normal Ruby classes. You can write Rails code within them. Eg. you can access your models.
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :string, default: Setting.find(1).yourvalue
end
end
Replace Setting.find(1) with whatever logic you need to filter.
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrapSetting.find(1)to check if the records exists before doing the change. else do a no-op migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
add a comment |
1
1
1
Migrations are normal Ruby classes. You can write Rails code within them. Eg. you can access your models.
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :string, default: Setting.find(1).yourvalue
end
end
Replace Setting.find(1) with whatever logic you need to filter.
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
Migrations are normal Ruby classes. You can write Rails code within them. Eg. you can access your models.
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :string, default: Setting.find(1).yourvalue
end
end
Replace Setting.find(1) with whatever logic you need to filter.
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
edited Nov 22 '18 at 3:56
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
answered Nov 22 '18 at 3:51
Lenin Raj RajasekaranLenin Raj Rajasekaran
16.1k1173116
16.1k1173116
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrapSetting.find(1)to check if the records exists before doing the change. else do a no-op migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
add a comment |
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrapSetting.find(1)to check if the records exists before doing the change. else do a no-op migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
This seems like a dangerous way to do it. What would the value be for a dropped and reloaded DB?
– cd-rum
Nov 22 '18 at 3:54
we could wrap
Setting.find(1) to check if the records exists before doing the change. else do a no-op migration– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
we could wrap
Setting.find(1) to check if the records exists before doing the change. else do a no-op migration– Lenin Raj Rajasekaran
Nov 22 '18 at 3:57
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
That's very true, but what's the advantage of storing that in the migration versus the class? I realise it was OP's question, but without advantages it seems needlessly dangerous
– cd-rum
Nov 22 '18 at 4:02
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
yes, that's what I said in my previous comment. we could check if it exists before doing the migration
– Lenin Raj Rajasekaran
Nov 22 '18 at 4:03
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
Sorry, started writing that before the comment updated. Edited.
– cd-rum
Nov 22 '18 at 4:06
add a comment |
1
I would set it on the model so your migrations remain non-reliant on previous states of the data therein.
class TableName < ApplicationRecord
before_create :add_defaults
# whatever
private
def add_defaults
self.column_name = Setting.find(1).default_value unless column_name
end
end
This way you won't be invoking ActiveRecord from the migration, and your app will still work if you deploy it somewhere and run the migrations before adding a Setting record. You'll likely need a fully-migrated database before adding any data.
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
add a comment |
1
I would set it on the model so your migrations remain non-reliant on previous states of the data therein.
class TableName < ApplicationRecord
before_create :add_defaults
# whatever
private
def add_defaults
self.column_name = Setting.find(1).default_value unless column_name
end
end
This way you won't be invoking ActiveRecord from the migration, and your app will still work if you deploy it somewhere and run the migrations before adding a Setting record. You'll likely need a fully-migrated database before adding any data.
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
add a comment |
1
1
1
I would set it on the model so your migrations remain non-reliant on previous states of the data therein.
class TableName < ApplicationRecord
before_create :add_defaults
# whatever
private
def add_defaults
self.column_name = Setting.find(1).default_value unless column_name
end
end
This way you won't be invoking ActiveRecord from the migration, and your app will still work if you deploy it somewhere and run the migrations before adding a Setting record. You'll likely need a fully-migrated database before adding any data.
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
I would set it on the model so your migrations remain non-reliant on previous states of the data therein.
class TableName < ApplicationRecord
before_create :add_defaults
# whatever
private
def add_defaults
self.column_name = Setting.find(1).default_value unless column_name
end
end
This way you won't be invoking ActiveRecord from the migration, and your app will still work if you deploy it somewhere and run the migrations before adding a Setting record. You'll likely need a fully-migrated database before adding any data.
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
answered Nov 22 '18 at 4:01
cd-rumcd-rum
3,54932862
3,54932862
add a comment |
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421461%2frails-default-to-a-defined-value%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What is the source of that value? where do you store it once user enters it?
– Lenin Raj Rajasekaran
Nov 21 '18 at 22:44
I eddited to include a settings model... this is purely hypothetical
– Joe Bloggs
Nov 21 '18 at 22:51
@settingsis a AR model row?– Lenin Raj Rajasekaran
Nov 21 '18 at 23:55
ar? i dont know what you mean
– Joe Bloggs
Nov 22 '18 at 3:08
@JoeBloggs he meant ActiveRecord
– Shiko
Nov 22 '18 at 3:14