Model's load(): DB_SQL::select(), not DB_ORM::select(). Why?

[djfd]

Is it correct? Just in case we need some customizations in a model (eg. transparent auto join I18n tables), we will need to override both of the proxies, DB_ORM_Select_Proxy and DB_SQL_Select_Proxy

Could any one explain?

As for me, it looks correct to use the same DB_ORM::select() inside model's load method...

thanks

[bluesnowman]

The primary difference between DB_ORM_Select_Proxy and DB_SQL_Select_Proxy is that table name is pulled directly from the model itself using DB_ORM_Select_Proxy, whereas the from method must be explicitly set using DB_SQL_Select_Proxy. The other difference is that you can create a builder extension class using DB_ORM_Select_Proxy, whereas DB_SQL_Select_Proxy does not permit that. It may be easier to modify DB_SQL_Select_Builder because both of these classes just forward everything to that class.

[djfd]

yeah, I saw that difference. but what is rationale behind of this choice? why we do use DB_SQL:: select() inside of model's load()?

e.g. $builder = DB_ORM::select(get_class($this), $columns)->limit(1); does the same

Semantically, DB_SQL::select() is pure SQL while DB_ORM::select() has relation to models and orm.

So why?

[djfd]

are there DB guys from kohana ORM forum? what do you think?

[bluesnowman]

@djfd I really don't have as to the exact reason for "why" this was done as much of the code was written many years ago. I agree that it does seem that we could use DB_ORM::select here instead if that would help decouple these two classes. If you would like to submit a pull request, I would will be help to review it and merge it in if everything looks good.

[djfd]

@bluesnowman

switched back to native kohana ORM. with a minor overrides it is capable to serve composite keys too, it is more habitual for me