Multiple polymorphic associations on the same object
I have a Flag model which is joined to multiple other objects with FlagInstance and a polymorphic flaggable on that table:
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
.....
With has many_through I'm able to fetch any flaggable object like user.flags which is great.
However I'm trying to flag objects with errors and the notify other objects so I've added
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
notifiable_id
notifiable_type
.....
The problem is, a User can have a flag and can be notified of a flag. So user.flags isn't specific enough to show me which is a flag and which is a notification of a flag.
I think I need to change the relationships:
user.rb
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
has_many :flags, through: :flag_instances
But I'm not sure what to change them to. Can someone please suggest a solution?
Note: both flags and notifications of flags can belong to multiple objects, so they both need to remain polymorphic.
Thanks
ruby-on-rails ruby ruby-on-rails-5 polymorphic-associations
add a comment |
I have a Flag model which is joined to multiple other objects with FlagInstance and a polymorphic flaggable on that table:
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
.....
With has many_through I'm able to fetch any flaggable object like user.flags which is great.
However I'm trying to flag objects with errors and the notify other objects so I've added
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
notifiable_id
notifiable_type
.....
The problem is, a User can have a flag and can be notified of a flag. So user.flags isn't specific enough to show me which is a flag and which is a notification of a flag.
I think I need to change the relationships:
user.rb
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
has_many :flags, through: :flag_instances
But I'm not sure what to change them to. Can someone please suggest a solution?
Note: both flags and notifications of flags can belong to multiple objects, so they both need to remain polymorphic.
Thanks
ruby-on-rails ruby ruby-on-rails-5 polymorphic-associations
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:flaggable_id, flaggable_type, notifiable_id, and notifiable_typecolumns?
– Surya
Nov 16 '18 at 10:50
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53
add a comment |
I have a Flag model which is joined to multiple other objects with FlagInstance and a polymorphic flaggable on that table:
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
.....
With has many_through I'm able to fetch any flaggable object like user.flags which is great.
However I'm trying to flag objects with errors and the notify other objects so I've added
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
notifiable_id
notifiable_type
.....
The problem is, a User can have a flag and can be notified of a flag. So user.flags isn't specific enough to show me which is a flag and which is a notification of a flag.
I think I need to change the relationships:
user.rb
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
has_many :flags, through: :flag_instances
But I'm not sure what to change them to. Can someone please suggest a solution?
Note: both flags and notifications of flags can belong to multiple objects, so they both need to remain polymorphic.
Thanks
ruby-on-rails ruby ruby-on-rails-5 polymorphic-associations
I have a Flag model which is joined to multiple other objects with FlagInstance and a polymorphic flaggable on that table:
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
.....
With has many_through I'm able to fetch any flaggable object like user.flags which is great.
However I'm trying to flag objects with errors and the notify other objects so I've added
table 'flag_instances'
flag_id
flaggable_id
flaggable_type
notifiable_id
notifiable_type
.....
The problem is, a User can have a flag and can be notified of a flag. So user.flags isn't specific enough to show me which is a flag and which is a notification of a flag.
I think I need to change the relationships:
user.rb
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
has_many :flags, through: :flag_instances
But I'm not sure what to change them to. Can someone please suggest a solution?
Note: both flags and notifications of flags can belong to multiple objects, so they both need to remain polymorphic.
Thanks
ruby-on-rails ruby ruby-on-rails-5 polymorphic-associations
ruby-on-rails ruby ruby-on-rails-5 polymorphic-associations
asked Nov 16 '18 at 10:07
David SigleyDavid Sigley
6271720
6271720
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:flaggable_id, flaggable_type, notifiable_id, and notifiable_typecolumns?
– Surya
Nov 16 '18 at 10:50
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53
add a comment |
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:flaggable_id, flaggable_type, notifiable_id, and notifiable_typecolumns?
– Surya
Nov 16 '18 at 10:50
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:
flaggable_id, flaggable_type, notifiable_id, and notifiable_type columns?– Surya
Nov 16 '18 at 10:50
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:
flaggable_id, flaggable_type, notifiable_id, and notifiable_type columns?– Surya
Nov 16 '18 at 10:50
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53
add a comment |
2 Answers
2
active
oldest
votes
Association for notifiable needs to be changed. In this case user.rb:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :notifiables, as: :notifiable, dependent: :destroy, class_name: 'FlagInstance'
has_many :notifications, through: :notifiables, class_name: 'Flag'
Note: You might also need to provide foreign_key in case Rails association is not able to pick up the key itself.
add a comment |
Each association must have a unique name - otherwise the later definition will just overwrite the former.
Here the third line overwrites the first line:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
To reference the correct associations we would need to setup the user model as so:
class User < ApplicationRecord
has_many :flag_instances_as_flaggable,
as: :flaggable
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
has_many :flag_instances_as_notifiable,
as: :notifiable
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
In your case you might want to use concerns to keep it dry:
module Flaggable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_flaggable,
as: :flaggable,
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
end
end
module Notifiable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_notifiable,
as: :notifiable,
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
end
class User < ApplicationRecord
include Flaggable
include Notifiable
end
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to addclass_name: 'FlagInstance'which is needed since the name of the class cannot be derided from the name of the association.
– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in thethough:association when you specifysource:as AR gets the class name from the association that its going though (Flag).
– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
|
show 1 more 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
});
}
});
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%2f53335560%2fmultiple-polymorphic-associations-on-the-same-object%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
Association for notifiable needs to be changed. In this case user.rb:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :notifiables, as: :notifiable, dependent: :destroy, class_name: 'FlagInstance'
has_many :notifications, through: :notifiables, class_name: 'Flag'
Note: You might also need to provide foreign_key in case Rails association is not able to pick up the key itself.
add a comment |
Association for notifiable needs to be changed. In this case user.rb:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :notifiables, as: :notifiable, dependent: :destroy, class_name: 'FlagInstance'
has_many :notifications, through: :notifiables, class_name: 'Flag'
Note: You might also need to provide foreign_key in case Rails association is not able to pick up the key itself.
add a comment |
Association for notifiable needs to be changed. In this case user.rb:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :notifiables, as: :notifiable, dependent: :destroy, class_name: 'FlagInstance'
has_many :notifications, through: :notifiables, class_name: 'Flag'
Note: You might also need to provide foreign_key in case Rails association is not able to pick up the key itself.
Association for notifiable needs to be changed. In this case user.rb:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :notifiables, as: :notifiable, dependent: :destroy, class_name: 'FlagInstance'
has_many :notifications, through: :notifiables, class_name: 'Flag'
Note: You might also need to provide foreign_key in case Rails association is not able to pick up the key itself.
answered Nov 16 '18 at 11:01
SuryaSurya
13.1k23558
13.1k23558
add a comment |
add a comment |
Each association must have a unique name - otherwise the later definition will just overwrite the former.
Here the third line overwrites the first line:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
To reference the correct associations we would need to setup the user model as so:
class User < ApplicationRecord
has_many :flag_instances_as_flaggable,
as: :flaggable
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
has_many :flag_instances_as_notifiable,
as: :notifiable
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
In your case you might want to use concerns to keep it dry:
module Flaggable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_flaggable,
as: :flaggable,
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
end
end
module Notifiable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_notifiable,
as: :notifiable,
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
end
class User < ApplicationRecord
include Flaggable
include Notifiable
end
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to addclass_name: 'FlagInstance'which is needed since the name of the class cannot be derided from the name of the association.
– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in thethough:association when you specifysource:as AR gets the class name from the association that its going though (Flag).
– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
|
show 1 more comment
Each association must have a unique name - otherwise the later definition will just overwrite the former.
Here the third line overwrites the first line:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
To reference the correct associations we would need to setup the user model as so:
class User < ApplicationRecord
has_many :flag_instances_as_flaggable,
as: :flaggable
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
has_many :flag_instances_as_notifiable,
as: :notifiable
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
In your case you might want to use concerns to keep it dry:
module Flaggable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_flaggable,
as: :flaggable,
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
end
end
module Notifiable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_notifiable,
as: :notifiable,
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
end
class User < ApplicationRecord
include Flaggable
include Notifiable
end
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to addclass_name: 'FlagInstance'which is needed since the name of the class cannot be derided from the name of the association.
– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in thethough:association when you specifysource:as AR gets the class name from the association that its going though (Flag).
– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
|
show 1 more comment
Each association must have a unique name - otherwise the later definition will just overwrite the former.
Here the third line overwrites the first line:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
To reference the correct associations we would need to setup the user model as so:
class User < ApplicationRecord
has_many :flag_instances_as_flaggable,
as: :flaggable
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
has_many :flag_instances_as_notifiable,
as: :notifiable
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
In your case you might want to use concerns to keep it dry:
module Flaggable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_flaggable,
as: :flaggable,
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
end
end
module Notifiable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_notifiable,
as: :notifiable,
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
end
class User < ApplicationRecord
include Flaggable
include Notifiable
end
Each association must have a unique name - otherwise the later definition will just overwrite the former.
Here the third line overwrites the first line:
has_many :flag_instances, as: :flaggable, dependent: :destroy
has_many :flags, through: :flag_instances
has_many :flag_instances, as: :notifiable, dependent: :destroy
To reference the correct associations we would need to setup the user model as so:
class User < ApplicationRecord
has_many :flag_instances_as_flaggable,
as: :flaggable
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
has_many :flag_instances_as_notifiable,
as: :notifiable
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
In your case you might want to use concerns to keep it dry:
module Flaggable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_flaggable,
as: :flaggable,
class_name: 'FlagInstance'
has_many :flags_as_flaggable,
through: :flag_instances_as_flaggable,
source: :flag
end
end
module Notifiable
extend ActiveSupport::Concern
included do
has_many :flag_instances_as_notifiable,
as: :notifiable,
class_name: 'FlagInstance'
has_many :flags_as_notifiable,
through: :flag_instances_as_notifiable,
source: :flag
end
end
class User < ApplicationRecord
include Flaggable
include Notifiable
end
edited Nov 16 '18 at 14:04
answered Nov 16 '18 at 13:52
maxmax
46.6k1060106
46.6k1060106
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to addclass_name: 'FlagInstance'which is needed since the name of the class cannot be derided from the name of the association.
– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in thethough:association when you specifysource:as AR gets the class name from the association that its going though (Flag).
– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
|
show 1 more comment
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to addclass_name: 'FlagInstance'which is needed since the name of the class cannot be derided from the name of the association.
– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in thethough:association when you specifysource:as AR gets the class name from the association that its going though (Flag).
– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I believe Suryas answer is correct. But just wondering, in your solution how does active record know to look in a table called flag_instances?
– David Sigley
Nov 16 '18 at 14:02
I actually forgot to add
class_name: 'FlagInstance' which is needed since the name of the class cannot be derided from the name of the association.– max
Nov 16 '18 at 14:06
I actually forgot to add
class_name: 'FlagInstance' which is needed since the name of the class cannot be derided from the name of the association.– max
Nov 16 '18 at 14:06
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Thought so. Thanks!
– David Sigley
Nov 16 '18 at 14:08
Its not needed in the
though: association when you specify source: as AR gets the class name from the association that its going though (Flag).– max
Nov 16 '18 at 14:08
Its not needed in the
though: association when you specify source: as AR gets the class name from the association that its going though (Flag).– max
Nov 16 '18 at 14:08
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
I would probably do this with a separate Notification model though instead of shoehorning everything into a single class. This lets you create a m-2-m association so that you can keep track of in-app notifications and for example email notifications.
– max
Nov 16 '18 at 14:14
|
show 1 more comment
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.
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%2f53335560%2fmultiple-polymorphic-associations-on-the-same-object%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
Do flag and notification have to be in same entry? What I mean is when a flag_instances entry is a flag, can it also be notification too at the same time? i.e. single entry has value in all 4:
flaggable_id, flaggable_type, notifiable_id, and notifiable_typecolumns?– Surya
Nov 16 '18 at 10:50
Yes, every entry will always have all 4 populated. Occasionally they'll have the same object in them, but usually it'll be different objects (E.G. Flag an AccessToken as expired and Notify a User)
– David Sigley
Nov 16 '18 at 10:53