problem with saving

Yii 1.1 General Discussion
1

some strange behavior -

made model for one message table in database, then after some time i added one int column -

and updated form for input to contain one more field for that new column.

but, after saving it via




$message->attributes=$_POST['message']; 

$message->save();

,

the new variable, only the new did not write to DB (everything else did). It was present in $_POST[‘message’] array, in debug window was insert into DB without that one field. Did some research, only method that worked, was




$message->setAttribute('rating',$_POST['message']['rating']);

then tryed some other things, and found that when i write some rule for that variable, then it starts working with $message->save() as intended.

Do i really allways need for each column in database have some rule?

or i forgot to define somewhere something? :)

only extension i have that may have some influence on that could be CAdvancedArBehavior.php

2

Yep as far as I know each user-submitted element is going to have to have a rule associated with it.

3

And this rule is called "safe":




public function rules()

{

    return array(

        array('fieldName', 'safe'),

        ...

    );

}
4

Hello,

which is the real use of the safe attribute?

I was looking for documentation. (http://www.yiiframework.com/doc/guide/form.model#safe-attributes-in-1-1) But it isn’t useful. It say that safe attribute is for make a attribute safe… :blink:

By the way, I have a problem we I update my model. In the form’s model there isn’t fields that updates the model. All the data is calculate with others values that are in the form.

Because of that, the $_POST[‘MODEL’] is unsset. I removed the line of code that check if the $_POST[‘MODEL’] is set.

Then I load the model and update one value and save. But the model doesn’t wanna save. The database is unchanged.

has the attribute save something in commonm with my problem??

5

All fields not listed in rules() are unsafe by default, so, if no special treatment need some field, but it IS safe, then this rule "safe" enters in action.

6

But, safe means… what exactly??

By the way, the problem I had. Instead of model->save() I use model->update(). Now, the model is updated correctly.::)

7

There were many topics where people asked what is "safe" for. For example:

http://www.yiiframework.com/forum/index.php?/topic/7715-ho-to-add-a-form-field-after-an-automatic-crud-generation

8

Thanks for answer :)

9

Since I am also running into these issues after upgrading I thought I’d comment. Perhaps it would be better to have the default for all fields be safe and allow the developer to mark which fields should not be safe. The majority of all my fields in all my tables are going to be populated by the user. DateEntered fields, Key fields or the like would be the exception. Springing this type of change with a much anticipated release has been frustrating.

At this point all my forms are broken. The project I’ve been working on for about five weeks is the blog demo that came with my original install and I’ve followed it closely. So, either the demo doesn’t adhere to the “rules” very well or there should be more DOCS on the importance of making attributes “SAFE” or else… Not to mention how to actually use them properly in different scenarios. Sorry to vent but I’ve pretty much wasted my entire weekend working on this upgrade… just when I thought I was beginning to make some progress on this stuff.

10

thank you andy_s

that really helped me

charles

11

Current patter is way better and safer. In real world you do not always need to populate all fields with massive assignements, like $model->attributes = $_POST[‘Model’]; There are attributes which in many cases should not be modified such way (for example - when updating users profile you do not want to change password, even if someone passes proper attribute in request. You have additional procedure to change password, which validates if user knows previous one, etc. Otherwise - hacker could easily change someones password. Now - people (coders also) are lazy, so if you relay on them to mark attributes “unsafe” in scenario when all atributes are “safe” by default you will end with everything left as generators did produce and your application unsafe and with real security holes. This is why everything is “unsafe” by default and you have to provide other rules.

In fact - you do not always need to specify attribute as “safe”, any other validation rule will do the same (for example: required, match, etc). This behavior forces you to provide validators, which is good :)