[Rodrigo Coelho]

@phpnode

I posted with these awesome ideas in mind. I believe that they'll make it to the core. I just don't know how. Maybe you're right.

[Rodrigo Coelho]

qiang, on 27 March 2012 - 11:03 AM, said:

I forgot to describe another important new feature: AR now can detect if an attribute is dirty or not, and by default it will only save dirty attributes to DB.

This would be so nice for the collection object when dealing with (and saving) related models.

[jacmoe]

It would be really interesting to see comparisons between old AR and new AR.
It looks like it's going to be a lot leaner, right?
In terms of performance, memory, etc. I mean.

[Mike]

Really nice stuff. What about validation rules? Any changes here?

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?

[qiang]

@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]

qiang, on 29 March 2012 - 09:09 AM, said:

@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]

qiang, on 29 March 2012 - 09:09 AM, said:

@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

[qiang]

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.

[Da:Sourcerer]

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 ...)

[Psih]

qiang, on 30 March 2012 - 09:05 AM, said:

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.

[johonunu]

New Active Record class looks very nice and clean.
I like asArray() method, similar to what CakePHP is doing.
I will only miss STAT relations

[jacmoe]

I am sure that either the Yii team or the community - or even both - will provide an alternative to STAT.

[phpnode]

I'm really hoping that the equivalent of STAT will be:

$model->hasManyOrManyManyRelation->count();

[Da:Sourcerer]

Da:Sourcerer, on 30 March 2012 - 10:27 AM, said:

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.

[Haensel]

@phpnode: I agree. Using relations to do a count() felt wrong anyway. I would expect relations to always return a single AR object or an array of objects, nothing else

[soso]

Hello,

Do you think of updating the scenario logic?

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.

Thanks.

[phpnode]

@qiang - Please can the ActiveQuery class have a getDataProvider() method?

e.g.

User::find()->someScope()->anotherScope()->getDataProvider();

It would also be really useful to have an easy way of getting a data provider for related records:

$user->photos->getDataProvider(); // photos is a has_many or many_many relation

[samdark]

Isn't it better to be able to pass an instance of ActiveFinder to the contructor of DataProvider? This way we'll not have a situation that lower level AR depends on higher level data provider.

[phpnode]

@samdark - perhaps, but in that case we should also be able to pass an ActiveRelation to the dataprovider's constructor too, e.g.

$dataProvider = new ActiveDataProvider($user->photos);

[dyulax]

I think here is not the best place, but anyway:

May be the search() method could be generated working with dates, times, and datetime attributes (+ i18n) and case insensitive strings (john will return JOHN).