Solved thread

This post is marked as solved. If you think the information contained on this thread must be part of the official documentation, please contribute submitting a pull request to its repository.

Why query builder returns incomplete object when use "columns"

As stated in the documentation https://docs.phalconphp.com/uk/latest/reference/models.html.

When use "columns" in query options ,

Return specific columns instead of the full columns in the model. When using this option an incomplete object is returned

Can you explain why this behavior please? and if there is any workaround on this issue to get The model object instead of Row instance?

Regards.

edited Sep '16

Because it's not full model and phalcon is using active record pattern. In active record pattern it would be really wrong to returnl partial model on which we can do save etc methods. What if we would return columns without id ? Or any other necessary columns to keep for example events working fine, like setting/transforming values etc ? Or validation or anything ? Or keep relations good etc ?

This is very good behaviour of phalcon framework - you need full model - then select it. Also Row object is "faster" than normal model object.



249

Thank you.

Let's assume that i'm aware of which columns being selected. but need to use the models objects instead of row, is there any Phalcon way to hydrate the partial records to models? as i'm using these columns for read only. since the table has too many columns is not used in my case.

Because it's not full model and phalcon is using active record pattern. In active record pattern it would be really wrong to returnl partial model on which we can do save etc methods. What if we would return columns without id ? Or any other necessary columns to keep for example events working fine, like setting/transforming values etc ? Or validation or anything ? Or keep relations good etc ?

This is very good behaviour of phalcon framework - you need full model - then select it. Also Row object is "faster" than normal model object.



99.6k
Accepted
answer
edited Sep '16

No, i wrote you above why. Only some dirt solutions, which im not aware of. As i already wrote:

need model - select full data

Why you need model exactly ? If you are selecting columns then it's obviously for displaying for example, why exactly you need for displaying full model ? Don't quite understand a problem.

I wrote you why it's happening, why it's good, and why you shouldn't use full model. Why you want full model when it's not full model ? I don't really understand what you are trying to do. It's like you read my answer, didn't even understand it and you still want to do something in wrong way. This is not limitation of framework as it is - we can implement such a stuff, but we shouldn't because it would be bad behaviour imho, why add bad stuff to framework ?

For me it's very good that phalcon don't allow hydrating partial to full model, it gives good consistency and your code is more clean. Just understand that phalcon is using ACTIVE RECORD PATTERN. If in active record pattern we could possibly hydrate partial object to full model this would become VERY BIG problem.



249

It seems such an angry reply.

I've table called "items". this table has many types of "items" , Blog Post, Pages, Gallery, Videos ... etc.

Every post type uses columns that may not used in another item. when selecting data based on such type. i need to select only related columns to the item type. i already select id and any required column for relations. I asked for full model to use model's relations "relation keys already added to columns " and some presenters methods.

It's ok , I will build custom implementaion to do that.

Thank you.

edited Sep '16

Then what's a problem with joins in query builder ? As i wrote - you are doing something wrong, just redone your database scheme or use joins.

It's not an angry reply. Im just trying to tell you that for 90% you are doing something wrong, why just don't do it properly ?



249

I really favour nullable columns over JOINS. sometimes joins is too expensive.

Thanks you.

Then as i wrote - this is just doing something wrong imho. Okay, fine, ignor good answers and do it in rubbish style, no problem.



249
edited Sep '16

I respect your opinion.

But i don't care if its good or rubish style when it comes to performance.

which is the core of Phalcon framework.

edited Sep '16

You should care about performance only when it will became a problem - not earlier. You shouldn't do rubbish code, or change your database schema because it affects performance....



249

I moved to Phalcon because of this.

You should care about performance only when it will became a problem

Good, but that doesn't mean that you should write bad code or do weird things.