Multiple polymorphic associations on the same object












1















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










share|improve this question























  • 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
















1















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










share|improve this question























  • 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














1












1








1








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










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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_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



















  • 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

















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












2 Answers
2






active

oldest

votes


















2














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.






share|improve this answer































    1














    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





    share|improve this answer


























    • 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













    • 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











    • 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












    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


















    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









    2














    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.






    share|improve this answer




























      2














      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.






      share|improve this answer


























        2












        2








        2







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 16 '18 at 11:01









        SuryaSurya

        13.1k23558




        13.1k23558

























            1














            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





            share|improve this answer


























            • 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













            • 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











            • 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
















            1














            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





            share|improve this answer


























            • 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













            • 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











            • 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














            1












            1








            1







            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





            share|improve this answer















            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






            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 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











            • 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 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













            • 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











            • 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


















            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














            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





















































            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







            Popular posts from this blog

            The Sandy Post

            Danny Elfman

            Pages that link to "Head v. Amoskeag Manufacturing Co."