Doctrine partial objects … is it for performance?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








1















i learnt that in doctrine i can return partial objects. when i just do print_r() of the result set returned, they seem to still contain the definations for the fields, except that when i echo them out i get nth. so i guess the definations are there but the values are not. is this for performance? eg. in SQL i shld do SELECT field1, field2 instead of SELECT *?










share|improve this question






























    1















    i learnt that in doctrine i can return partial objects. when i just do print_r() of the result set returned, they seem to still contain the definations for the fields, except that when i echo them out i get nth. so i guess the definations are there but the values are not. is this for performance? eg. in SQL i shld do SELECT field1, field2 instead of SELECT *?










    share|improve this question


























      1












      1








      1








      i learnt that in doctrine i can return partial objects. when i just do print_r() of the result set returned, they seem to still contain the definations for the fields, except that when i echo them out i get nth. so i guess the definations are there but the values are not. is this for performance? eg. in SQL i shld do SELECT field1, field2 instead of SELECT *?










      share|improve this question
















      i learnt that in doctrine i can return partial objects. when i just do print_r() of the result set returned, they seem to still contain the definations for the fields, except that when i echo them out i get nth. so i guess the definations are there but the values are not. is this for performance? eg. in SQL i shld do SELECT field1, field2 instead of SELECT *?







      sql doctrine






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 16 '18 at 12:46









      Ravipati Praveen

      126420




      126420










      asked Jul 24 '10 at 6:56









      Jiew MengJiew Meng

      20.5k141379643




      20.5k141379643






















          3 Answers
          3






          active

          oldest

          votes


















          0














          As far as I can tell, the ability to select just partial objects is, as you say, for performance. However, unless your table is very large, or contains columns with large sized data, I doubt there is a very large effect.



          Doctrine can lazy-load the values in columns that are not selected when the object is first created. This can create performance problems, as Doctrine will perform more queries to get the missing data, so try to always make sure the data you use is selected.






          share|improve this answer























          • varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

            – prograhammer
            Mar 20 '15 at 2:38






          • 1





            @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

            – Jani Hartikainen
            Mar 20 '15 at 12:48











          • Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

            – prograhammer
            Mar 20 '15 at 13:25











          • @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

            – Jani Hartikainen
            Mar 21 '15 at 16:26


















          0














          I don't understand you question completely but in DQL you can do SELECT * since the ORM will always create a SELECT field1, field2,.... query out of it.



          With regular SQL, you should avoid SELECTing * since it will decrease performance.






          share|improve this answer






























            0














            Partial queries is very useful it you want results that does not include various data such as passwords and such.



            I use it for my REST API whereas I don't want to return data such as the User object's password.



            Example might be:



             SELECT .... JOIN ... partial user.user_id, email .... 


            And then return array with Query::HYDRATE_ARRAY. Obviously it would not make that much sense if you didn't hydrate your result.



            This is useful because you don't want to retrieve the users hashed password for everyone to see ( that is in a REST API where you send data to client applications such as backbone driven, or even iPhone/Android apps ) .






            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',
              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%2f3324155%2fdoctrine-partial-objects-is-it-for-performance%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              3 Answers
              3






              active

              oldest

              votes








              3 Answers
              3






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              0














              As far as I can tell, the ability to select just partial objects is, as you say, for performance. However, unless your table is very large, or contains columns with large sized data, I doubt there is a very large effect.



              Doctrine can lazy-load the values in columns that are not selected when the object is first created. This can create performance problems, as Doctrine will perform more queries to get the missing data, so try to always make sure the data you use is selected.






              share|improve this answer























              • varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

                – prograhammer
                Mar 20 '15 at 2:38






              • 1





                @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

                – Jani Hartikainen
                Mar 20 '15 at 12:48











              • Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

                – prograhammer
                Mar 20 '15 at 13:25











              • @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

                – Jani Hartikainen
                Mar 21 '15 at 16:26















              0














              As far as I can tell, the ability to select just partial objects is, as you say, for performance. However, unless your table is very large, or contains columns with large sized data, I doubt there is a very large effect.



              Doctrine can lazy-load the values in columns that are not selected when the object is first created. This can create performance problems, as Doctrine will perform more queries to get the missing data, so try to always make sure the data you use is selected.






              share|improve this answer























              • varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

                – prograhammer
                Mar 20 '15 at 2:38






              • 1





                @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

                – Jani Hartikainen
                Mar 20 '15 at 12:48











              • Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

                – prograhammer
                Mar 20 '15 at 13:25











              • @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

                – Jani Hartikainen
                Mar 21 '15 at 16:26













              0












              0








              0







              As far as I can tell, the ability to select just partial objects is, as you say, for performance. However, unless your table is very large, or contains columns with large sized data, I doubt there is a very large effect.



              Doctrine can lazy-load the values in columns that are not selected when the object is first created. This can create performance problems, as Doctrine will perform more queries to get the missing data, so try to always make sure the data you use is selected.






              share|improve this answer













              As far as I can tell, the ability to select just partial objects is, as you say, for performance. However, unless your table is very large, or contains columns with large sized data, I doubt there is a very large effect.



              Doctrine can lazy-load the values in columns that are not selected when the object is first created. This can create performance problems, as Doctrine will perform more queries to get the missing data, so try to always make sure the data you use is selected.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Jul 25 '10 at 10:10









              Jani HartikainenJani Hartikainen

              36.1k95580




              36.1k95580












              • varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

                – prograhammer
                Mar 20 '15 at 2:38






              • 1





                @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

                – Jani Hartikainen
                Mar 20 '15 at 12:48











              • Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

                – prograhammer
                Mar 20 '15 at 13:25











              • @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

                – Jani Hartikainen
                Mar 21 '15 at 16:26

















              • varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

                – prograhammer
                Mar 20 '15 at 2:38






              • 1





                @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

                – Jani Hartikainen
                Mar 20 '15 at 12:48











              • Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

                – prograhammer
                Mar 20 '15 at 13:25











              • @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

                – Jani Hartikainen
                Mar 21 '15 at 16:26
















              varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

              – prograhammer
              Mar 20 '15 at 2:38





              varchar and text fields can easily eat up the performance, hence why SELECTing carefully is import. I'm currently considering using Doctrine, but I'm a little wary of how eager it seems to want to do SELECT *.

              – prograhammer
              Mar 20 '15 at 2:38




              1




              1





              @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

              – Jani Hartikainen
              Mar 20 '15 at 12:48





              @DavidGraham used it in a number of projects, it always performed adequately for the purposes, but we never stored any particularly large blobs.

              – Jani Hartikainen
              Mar 20 '15 at 12:48













              Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

              – prograhammer
              Mar 20 '15 at 13:25





              Yes, but consider you have a complex project with several JOINs in your queries. Doctrine is going to grab every single field from all your associations. I'm not storing blobs in the main tables that I work with, but I do have an amount of varchars that (considering the number of rows I want displayed, and the number of users hitting those queries) could be a problem. I just think that there is no silver-bullet with attacking the database as OO. So to add bloat, may not be the best choice. I'm considering it, I just sort of see ORMs as an anti-pattern right now. Trying to warm up to them.

              – prograhammer
              Mar 20 '15 at 13:25













              @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

              – Jani Hartikainen
              Mar 21 '15 at 16:26





              @DavidGraham They're a tool where any other... They do certain things well, others not so much :) Personally I find they make writing most DB code a lot easier and faster, and at least in Doctrine 2's case, if you find it doesn't perform well in a certain use-case, it's easy to replace with a raw SQL query or such.

              – Jani Hartikainen
              Mar 21 '15 at 16:26













              0














              I don't understand you question completely but in DQL you can do SELECT * since the ORM will always create a SELECT field1, field2,.... query out of it.



              With regular SQL, you should avoid SELECTing * since it will decrease performance.






              share|improve this answer



























                0














                I don't understand you question completely but in DQL you can do SELECT * since the ORM will always create a SELECT field1, field2,.... query out of it.



                With regular SQL, you should avoid SELECTing * since it will decrease performance.






                share|improve this answer

























                  0












                  0








                  0







                  I don't understand you question completely but in DQL you can do SELECT * since the ORM will always create a SELECT field1, field2,.... query out of it.



                  With regular SQL, you should avoid SELECTing * since it will decrease performance.






                  share|improve this answer













                  I don't understand you question completely but in DQL you can do SELECT * since the ORM will always create a SELECT field1, field2,.... query out of it.



                  With regular SQL, you should avoid SELECTing * since it will decrease performance.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jul 25 '10 at 9:54









                  DrColossosDrColossos

                  10.5k23661




                  10.5k23661





















                      0














                      Partial queries is very useful it you want results that does not include various data such as passwords and such.



                      I use it for my REST API whereas I don't want to return data such as the User object's password.



                      Example might be:



                       SELECT .... JOIN ... partial user.user_id, email .... 


                      And then return array with Query::HYDRATE_ARRAY. Obviously it would not make that much sense if you didn't hydrate your result.



                      This is useful because you don't want to retrieve the users hashed password for everyone to see ( that is in a REST API where you send data to client applications such as backbone driven, or even iPhone/Android apps ) .






                      share|improve this answer



























                        0














                        Partial queries is very useful it you want results that does not include various data such as passwords and such.



                        I use it for my REST API whereas I don't want to return data such as the User object's password.



                        Example might be:



                         SELECT .... JOIN ... partial user.user_id, email .... 


                        And then return array with Query::HYDRATE_ARRAY. Obviously it would not make that much sense if you didn't hydrate your result.



                        This is useful because you don't want to retrieve the users hashed password for everyone to see ( that is in a REST API where you send data to client applications such as backbone driven, or even iPhone/Android apps ) .






                        share|improve this answer

























                          0












                          0








                          0







                          Partial queries is very useful it you want results that does not include various data such as passwords and such.



                          I use it for my REST API whereas I don't want to return data such as the User object's password.



                          Example might be:



                           SELECT .... JOIN ... partial user.user_id, email .... 


                          And then return array with Query::HYDRATE_ARRAY. Obviously it would not make that much sense if you didn't hydrate your result.



                          This is useful because you don't want to retrieve the users hashed password for everyone to see ( that is in a REST API where you send data to client applications such as backbone driven, or even iPhone/Android apps ) .






                          share|improve this answer













                          Partial queries is very useful it you want results that does not include various data such as passwords and such.



                          I use it for my REST API whereas I don't want to return data such as the User object's password.



                          Example might be:



                           SELECT .... JOIN ... partial user.user_id, email .... 


                          And then return array with Query::HYDRATE_ARRAY. Obviously it would not make that much sense if you didn't hydrate your result.



                          This is useful because you don't want to retrieve the users hashed password for everyone to see ( that is in a REST API where you send data to client applications such as backbone driven, or even iPhone/Android apps ) .







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Aug 19 '12 at 3:04









                          Petter KjelkenesPetter Kjelkenes

                          1,17211525




                          1,17211525



























                              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%2f3324155%2fdoctrine-partial-objects-is-it-for-performance%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

                              Top Tejano songwriter Luis Silva dead of heart attack at 64

                              政党

                              天津地下鉄3号線