Why was a custom ORM implementation chosen (ActiveRecord) over a pre-existing ORM solution?
Why not PHPActiveRecord (or is it in fact PHPActiveRecord?)? Or Doctrine? Or any of the other ORMs now available for PHP?
I’ve only recently come across Yii and I’m definitely liking what I’m seeing but my background for a framework is Symfony and their choice was to go with a pre-existing ORM. Why didn’t Yii?
Cause Yii makes heavily use of autoloading, and as far as I know both (or everything else) dont use Autoloading as "hard" as Yii does. But if you want to use it you could easily implement it. Just look at the doctrine extension for Yii how it is done.
Nevertheless: The ORM in Yii is horrible, I guess the Yii developers know it but they wont change it in future to keep comparability 
Why? (I’ve never worked with any other ORM)
food for thought ~
PHPActiveRecord, and Doctrine both good thing, i think!
Can some one please give a compare of Yii AR and any other ORM (and not just own opinion)?
I use Yii AR and don’t see any obvious defects. It suits my needs pretty well.
Thanks to all for the responses.
Some of the features that I’ve grown accustomed to when using Doctrine in the past are it’s file-based schema configuration that allows generation of the database as well as the models and it’s incredibly useful migrations (also available in RoR). I realize that there are plugins for both Doctrine and DBMigrations for Yii but it does raise a concern that they were not considered for the initial implementation. Are there plans to integrate these features into ActiveRecord? If not, why?
After running through some test usages and reading the “Definite Guide” I’m also noticing that the models generated from the database have no base class. If I were to create my initial database structure, generate models from those tables and then have a need to change the structure in the future (which is very often the case) any changes I’ve made to the model files will be overwritten if I regenerate, forcing me to do manual merging. If base classes were generated and empty extending classes were made available as the actual model (BaseUser and User [extends BaseUser]) then this could be avoided altogether. Why is this not done?
I’m not trying to speak ill of the framework by any means, I am enjoying the approach and simplicity so far, but these features have been around for some time now and to me are functionality that I’ve grown to expect. Any help on the topic would be greatly appreciated.
Qiang is seriously thinking about adding database migrations to Yii. I think it may come before too long.
I’ve never used any active record systems besides Yii’s and CakePHP’s, but I would assume the reason Yii has a custom one is so that it is more consistent with the way the rest of the framework works (pretty much everything in Yii extends CComponent including AR).
What implemented in Yii is not ORM. It’s AR so comparing it to ORM such as Doctrine or Propel is not correct.
Perhaps my question could be better worded. Why wasn’t a pre-existing ActiveRecord PHP implementation used (such as PHPActiveRecord) in Yii?
So far possible reasons have been support for Yii’s auto-loading as well as consistency. Any other possibilities?
More importantly, why was an ORM avoided? Doctrine, a prominent PHP ORM, employs the ActiveRecord model in its implementation, is there a reason that this and other ORMs were passed over when implementing Yii?
I ask because I’m trying to realign my previous experience with the design decisions inherent in Yii. Any help is appreciated.
Glad to hear it, thanks. I’m still digging through all of the resources available, is there a development roadmap or something similar for Yii that’s publicly available?
@cryo: thank you for raising this question. I hope my answers will help clarify your doubts.
First, ActiveRecord in Yii actually has much longer history than most other PHP ActiveRecord implementation (including PHPActiveRecord). The history of Yii AR can be dated back to year 2005 when we developed ActiveRecord support in Prado. Ever since then, our AR implementation has been used extensively and been continuously improved. While the AR implementation in Yii is still not perfect, we believe it should satisfy most of our needs and we will continue to improve it.
Second, we consider ActiveRecord an important part of an MVC framework because it is the foundation of the "M" part. We do not want the core of our framework to rely on a third-party implementation because it would otherwise mean the quality of the framework is beyond our control. From the user point of view, having a framework-supported AR is also a good thing because its quality can be depended on and its usage is more consistent with the rest part of the framework.
Third, as samdark said, AR is not equivalent to ORM. If AR doesn’t fit for your needs, you may consider using Doctrine or other ORM tools. Some users have reported the success of using Doctrine in Yii.
Regarding the roadmap of Yii, at this stage, our development is mainly driven by user-raised feature requests. We also have certain features in our mind that we will implement in future. We use google project ticket tracker to keep track of these requests.
The main reasons that Yii doesn’t use base AR class is because AR automatically detects the latest available table columns and the base class won’t change even if your table definition is changed. If you insist on defining base classes, you will find the base classes only contains the following code, which is too trivial to serve as a separate class:
class PostBase extends CActiveRecord {
public static function model($class=__CLASS__) {
return parent::model($class);
}
}
Thank you very much for the detailed responses, that information is exactly what I was looking for.