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;
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
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
add a comment |
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
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
add a comment |
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
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
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
sql doctrine
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
edited Nov 16 '18 at 12:46
Ravipati Praveen
126420
126420
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
asked Jul 24 '10 at 6:56
Jiew MengJiew Meng
20.5k141379643
20.5k141379643
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
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.
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
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
add a comment |
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.
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
add a comment |
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 ) .
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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%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
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.
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
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
add a comment |
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.
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
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
add a comment |
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.
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
36.1k95580
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.
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
36.1k95580
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
36.1k95580
answered Jul 25 '10 at 10:10
Jani HartikainenJani Hartikainen
36.1k95580
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
add a comment |
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
add a comment |
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.
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
add a comment |
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.
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
add a comment |
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.
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
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.
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
answered Jul 25 '10 at 9:54
DrColossosDrColossos
10.5k23661
10.5k23661
add a comment |
add a comment |
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 ) .
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
add a comment |
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 ) .
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
add a comment |
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 ) .
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
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 ) .
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
answered Aug 19 '12 at 3:04
Petter KjelkenesPetter Kjelkenes
1,17211525
1,17211525
add a comment |
add a 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%2f3324155%2fdoctrine-partial-objects-is-it-for-performance%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
