Kohana 3.1 Validation + Standard ORM?

Question

ORM

Show with an example how you validate data when creating two related models.
Input:
There is a user ORM model and a user_contacts ORM model. In theory, we should describe all validation, filters in models using function rules() and function filters(). We must catch validation errors using the try{}catch(){} construct. The user_contacts model cannot be created without the user model. Data is entered and submitted in one go (one form per two models). In the user model, in addition to the rules of the model itself, $external_validation is also created before saving to check if the name is busy.
Question: How to first check the data, and if everything is correct for both models, only then save the models?
- When checking in turn, the first model will throw an exception, we will not be able to deduce errors from the second model, if any.
- If we save the first one first, and the second model throws an exception, we will have to delete the first one, which is not very beautiful.
- If you pass the validation of the second model to the save method of the first one, then it is not clear where to put the check for the busyness of the login (In theory, it should only work with create, and should not be called with every model change, so you cannot insert this check into the model rules)
- We can validate both models before the try{}catch(){} block, but there will be a problem if the second model also has $external_validation inside the model.

Answer 1

1. Why name validation via $external_validation? What prevents you from simply adding a rule (as done in Auth )?
2. In general, for me personally, the second model (User_Contacts) is not mandatory. Accordingly, I see two options:
* save the first model and ask the user to edit the contacts. Even if he does not save them, they are optional (well, or we will persistently ask them if we still need them)
* save the first model + those fields that have passed validation. Everything that did not pass due to errors is shown to the user. I like this option better.
In general, we do not worry about transactions, but uniquely depend only on the correctness of the first model (it is our main one).