build methods for has_one though has_one











up vote
0
down vote

favorite












Rails 5.1.2
Ruby 2.5.3



I understand there are multiple ways to impliment this relationship, however, this question is more about why the following doesn't work rather than solving a real world problem.



has_many setup



class Subscriber < ApplicationRecord
has_many :subscriptions, inverse_of: :subscriber
has_many :promotions, through: :subscriptions, inverse_of: :subscriptions

accepts_nested_attributes_for :subscriptions
accepts_nested_attributes_for :promotions
end

class Subscription < ApplicationRecord
belongs_to :subscriber, inverse_of: :subscriptions
belongs_to :promotion, inverse_of: :subscriptions
end

class Promotion < ApplicationRecord
has_many :subscriptions, inverse_of: :promotion
has_many :subscribers, through: :subscriptions, inverse_of: :subscriptions

accepts_nested_attributes_for :subscriptions
accepts_nested_attributes_for :subscribers
end


In the above Subscriber model which is setup to use has_many relationships following would work:



s = Subscriber.new
s.subscriptions.build
# OR
s.promotions.build


Following that, I would expect Subscriber to behave the same way with has_one relationships



has_one setup



class Subscriber < ApplicationRecord
has_one :subscription, inverse_of: :subscriber
has_one :promotion, through: :subscription, inverse_of: :subscriptions

accepts_nested_attributes_for :subscription
accepts_nested_attributes_for :promotion
end

class Subscription < ApplicationRecord
belongs_to :subscriber, inverse_of: :subscription
belongs_to :promotion, inverse_of: :subscriptions
end

class Promotion < ApplicationRecord
has_many :subscriptions, inverse_of: :promotion
has_many :subscribers, through: :subscriptions, inverse_of: :subscription

accepts_nested_attributes_for :subscriptions
accepts_nested_attributes_for :subscribers
end


However, attempting to build the nested promotion association with the equivalent has_one build methods results in a NoMethodError (undefined method 'build_promotion' for #<Subscriber:0x00007f9042cbd7c8>) error



s = Subscriber.new
s.build_promotion


However, this does work:



s = Subscriber.new
s.build_subscription


I feel it's logical that one should expect to build nested has_one relationships in the same way one builds has_many.



Is this a bug or by design?










share|improve this question




























    up vote
    0
    down vote

    favorite












    Rails 5.1.2
    Ruby 2.5.3



    I understand there are multiple ways to impliment this relationship, however, this question is more about why the following doesn't work rather than solving a real world problem.



    has_many setup



    class Subscriber < ApplicationRecord
    has_many :subscriptions, inverse_of: :subscriber
    has_many :promotions, through: :subscriptions, inverse_of: :subscriptions

    accepts_nested_attributes_for :subscriptions
    accepts_nested_attributes_for :promotions
    end

    class Subscription < ApplicationRecord
    belongs_to :subscriber, inverse_of: :subscriptions
    belongs_to :promotion, inverse_of: :subscriptions
    end

    class Promotion < ApplicationRecord
    has_many :subscriptions, inverse_of: :promotion
    has_many :subscribers, through: :subscriptions, inverse_of: :subscriptions

    accepts_nested_attributes_for :subscriptions
    accepts_nested_attributes_for :subscribers
    end


    In the above Subscriber model which is setup to use has_many relationships following would work:



    s = Subscriber.new
    s.subscriptions.build
    # OR
    s.promotions.build


    Following that, I would expect Subscriber to behave the same way with has_one relationships



    has_one setup



    class Subscriber < ApplicationRecord
    has_one :subscription, inverse_of: :subscriber
    has_one :promotion, through: :subscription, inverse_of: :subscriptions

    accepts_nested_attributes_for :subscription
    accepts_nested_attributes_for :promotion
    end

    class Subscription < ApplicationRecord
    belongs_to :subscriber, inverse_of: :subscription
    belongs_to :promotion, inverse_of: :subscriptions
    end

    class Promotion < ApplicationRecord
    has_many :subscriptions, inverse_of: :promotion
    has_many :subscribers, through: :subscriptions, inverse_of: :subscription

    accepts_nested_attributes_for :subscriptions
    accepts_nested_attributes_for :subscribers
    end


    However, attempting to build the nested promotion association with the equivalent has_one build methods results in a NoMethodError (undefined method 'build_promotion' for #<Subscriber:0x00007f9042cbd7c8>) error



    s = Subscriber.new
    s.build_promotion


    However, this does work:



    s = Subscriber.new
    s.build_subscription


    I feel it's logical that one should expect to build nested has_one relationships in the same way one builds has_many.



    Is this a bug or by design?










    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      Rails 5.1.2
      Ruby 2.5.3



      I understand there are multiple ways to impliment this relationship, however, this question is more about why the following doesn't work rather than solving a real world problem.



      has_many setup



      class Subscriber < ApplicationRecord
      has_many :subscriptions, inverse_of: :subscriber
      has_many :promotions, through: :subscriptions, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :promotions
      end

      class Subscription < ApplicationRecord
      belongs_to :subscriber, inverse_of: :subscriptions
      belongs_to :promotion, inverse_of: :subscriptions
      end

      class Promotion < ApplicationRecord
      has_many :subscriptions, inverse_of: :promotion
      has_many :subscribers, through: :subscriptions, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :subscribers
      end


      In the above Subscriber model which is setup to use has_many relationships following would work:



      s = Subscriber.new
      s.subscriptions.build
      # OR
      s.promotions.build


      Following that, I would expect Subscriber to behave the same way with has_one relationships



      has_one setup



      class Subscriber < ApplicationRecord
      has_one :subscription, inverse_of: :subscriber
      has_one :promotion, through: :subscription, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscription
      accepts_nested_attributes_for :promotion
      end

      class Subscription < ApplicationRecord
      belongs_to :subscriber, inverse_of: :subscription
      belongs_to :promotion, inverse_of: :subscriptions
      end

      class Promotion < ApplicationRecord
      has_many :subscriptions, inverse_of: :promotion
      has_many :subscribers, through: :subscriptions, inverse_of: :subscription

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :subscribers
      end


      However, attempting to build the nested promotion association with the equivalent has_one build methods results in a NoMethodError (undefined method 'build_promotion' for #<Subscriber:0x00007f9042cbd7c8>) error



      s = Subscriber.new
      s.build_promotion


      However, this does work:



      s = Subscriber.new
      s.build_subscription


      I feel it's logical that one should expect to build nested has_one relationships in the same way one builds has_many.



      Is this a bug or by design?










      share|improve this question















      Rails 5.1.2
      Ruby 2.5.3



      I understand there are multiple ways to impliment this relationship, however, this question is more about why the following doesn't work rather than solving a real world problem.



      has_many setup



      class Subscriber < ApplicationRecord
      has_many :subscriptions, inverse_of: :subscriber
      has_many :promotions, through: :subscriptions, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :promotions
      end

      class Subscription < ApplicationRecord
      belongs_to :subscriber, inverse_of: :subscriptions
      belongs_to :promotion, inverse_of: :subscriptions
      end

      class Promotion < ApplicationRecord
      has_many :subscriptions, inverse_of: :promotion
      has_many :subscribers, through: :subscriptions, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :subscribers
      end


      In the above Subscriber model which is setup to use has_many relationships following would work:



      s = Subscriber.new
      s.subscriptions.build
      # OR
      s.promotions.build


      Following that, I would expect Subscriber to behave the same way with has_one relationships



      has_one setup



      class Subscriber < ApplicationRecord
      has_one :subscription, inverse_of: :subscriber
      has_one :promotion, through: :subscription, inverse_of: :subscriptions

      accepts_nested_attributes_for :subscription
      accepts_nested_attributes_for :promotion
      end

      class Subscription < ApplicationRecord
      belongs_to :subscriber, inverse_of: :subscription
      belongs_to :promotion, inverse_of: :subscriptions
      end

      class Promotion < ApplicationRecord
      has_many :subscriptions, inverse_of: :promotion
      has_many :subscribers, through: :subscriptions, inverse_of: :subscription

      accepts_nested_attributes_for :subscriptions
      accepts_nested_attributes_for :subscribers
      end


      However, attempting to build the nested promotion association with the equivalent has_one build methods results in a NoMethodError (undefined method 'build_promotion' for #<Subscriber:0x00007f9042cbd7c8>) error



      s = Subscriber.new
      s.build_promotion


      However, this does work:



      s = Subscriber.new
      s.build_subscription


      I feel it's logical that one should expect to build nested has_one relationships in the same way one builds has_many.



      Is this a bug or by design?







      ruby-on-rails has-one-through






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 10 at 21:55

























      asked Nov 10 at 21:40









      Eric Norcross

      2,24421937




      2,24421937
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote



          accepted










          Checking the code, when you call has_one, it creates the build_, create_ and create_..! methods ONLY if the reflection is "constructable"



          https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/lib/active_record/associations/builder/singular_association.rb#L16



          define_constructors(mixin, name) if reflection.constructable?


          Now, checking the constructable? method, it returns the result of calculate_constructable https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L452



          And for the HasOne class, it returns false if you use the :through option https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L723



          def calculate_constructable(macro, options)
          !options[:through]
          end


          So, I'd say it's not a bug, it's made like that by design. I don't know the reason though, maybe it feels logical but I guess there's some things to consider that are not that simple.






          share|improve this answer





















            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',
            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%2f53243674%2fbuild-methods-for-has-one-though-has-one%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote



            accepted










            Checking the code, when you call has_one, it creates the build_, create_ and create_..! methods ONLY if the reflection is "constructable"



            https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/lib/active_record/associations/builder/singular_association.rb#L16



            define_constructors(mixin, name) if reflection.constructable?


            Now, checking the constructable? method, it returns the result of calculate_constructable https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L452



            And for the HasOne class, it returns false if you use the :through option https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L723



            def calculate_constructable(macro, options)
            !options[:through]
            end


            So, I'd say it's not a bug, it's made like that by design. I don't know the reason though, maybe it feels logical but I guess there's some things to consider that are not that simple.






            share|improve this answer

























              up vote
              0
              down vote



              accepted










              Checking the code, when you call has_one, it creates the build_, create_ and create_..! methods ONLY if the reflection is "constructable"



              https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/lib/active_record/associations/builder/singular_association.rb#L16



              define_constructors(mixin, name) if reflection.constructable?


              Now, checking the constructable? method, it returns the result of calculate_constructable https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L452



              And for the HasOne class, it returns false if you use the :through option https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L723



              def calculate_constructable(macro, options)
              !options[:through]
              end


              So, I'd say it's not a bug, it's made like that by design. I don't know the reason though, maybe it feels logical but I guess there's some things to consider that are not that simple.






              share|improve this answer























                up vote
                0
                down vote



                accepted







                up vote
                0
                down vote



                accepted






                Checking the code, when you call has_one, it creates the build_, create_ and create_..! methods ONLY if the reflection is "constructable"



                https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/lib/active_record/associations/builder/singular_association.rb#L16



                define_constructors(mixin, name) if reflection.constructable?


                Now, checking the constructable? method, it returns the result of calculate_constructable https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L452



                And for the HasOne class, it returns false if you use the :through option https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L723



                def calculate_constructable(macro, options)
                !options[:through]
                end


                So, I'd say it's not a bug, it's made like that by design. I don't know the reason though, maybe it feels logical but I guess there's some things to consider that are not that simple.






                share|improve this answer












                Checking the code, when you call has_one, it creates the build_, create_ and create_..! methods ONLY if the reflection is "constructable"



                https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/lib/active_record/associations/builder/singular_association.rb#L16



                define_constructors(mixin, name) if reflection.constructable?


                Now, checking the constructable? method, it returns the result of calculate_constructable https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L452



                And for the HasOne class, it returns false if you use the :through option https://github.com/rails/rails/blob/ed1eda271c7ac82ecb7bd94b6fa1b0093e648a3e/activerecord/lib/active_record/reflection.rb#L723



                def calculate_constructable(macro, options)
                !options[:through]
                end


                So, I'd say it's not a bug, it's made like that by design. I don't know the reason though, maybe it feels logical but I guess there's some things to consider that are not that simple.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 10 at 22:49









                arieljuod

                5,63711121




                5,63711121






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53243674%2fbuild-methods-for-has-one-though-has-one%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

                    Xamarin.iOS Cant Deploy on Iphone

                    Glorious Revolution

                    Dulmage-Mendelsohn matrix decomposition in Python