I wasn't very happy that in 1.1.x the definition of validation rules was combined with the definition of safe attributes (it was separate in 1.0.x). For big models with several scenarios it made rules() bloated. But i could override getSafeAttributeNames() to keep things a bit more separated. Will this still be possible? Or did it also change completely?

@Psih: I'm not sure if this extension still works. It allows you to use native drivers.

@Mike: No, validation rules are largely unchanged. If you have many scenarios in a model, for better organization you could put the rules for different scenarios in different functions and then merge them in rules().

@Mike: No, validation rules are largely unchanged. If you have many scenarios in a model, for better organization you could put the rules for different scenarios in different functions and then merge them in rules().

Well, that's not quite the same: I really want a separation of safe attributes from validation rules. As long as that's still possible (overriding getSafeAttributeNames or similar), i'm happy. I just don't want to list different sets of scenarios on every rule all the time as it makes my validation code very lengthy.

@Psih: I'm not sure if this extension still works. It allows you to use native drivers.

I've checked it, yes. That's the first thing that come up. But essentially it is PDO implementation to the letter without exposing any additional functionality to CDbConnection, so you can't use any driver-specific functionality at all. It's just a drop-in emulation if there is no PDO available.
I'm willing to try to do something about this for the Yii 2, but I need access to the source to see what can be or can't be done about it

It is possible to expose driver-specific functions through this PDO protocol. The new DB connection class is largely the same as 1.1. If your implementation of this PDO emulation is complete, we may consider including it into the core. Since we are still actively developing 2.0, we won't release the source code to public before it is relatively stable.

Are there any plans for intercepting events (similar to how filters work now for controllers)? Because then we could implement things like identity maps as a behavior. (Got to admit: That's for now the only use case I can imagine ...)

programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code

It is possible to expose driver-specific functions through this PDO protocol. The new DB connection class is largely the same as 1.1. If your implementation of this PDO emulation is complete, we may consider including it into the core. Since we are still actively developing 2.0, we won't release the source code to public before it is relatively stable.

Ok, i will do the work in next few week and will see if it works out fine.

Are there any plans for intercepting events (similar to how filters work now for controllers)? Because then we could implement things like identity maps as a behavior. (Got to admit: That's for now the only use case I can imagine ...)

Hm, actually ... Caching for active records could be implemented as a behavior this way, too.

programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code

For example, v1 implementation if you have a rule for the default scenario for a field as 'required' then it isn't possible to make the field not required in a custom scenario. I bumped into something like this, I simply needed the field to not be required anymore in a custom scenrario, something like 'safe' only.