I am looking for someone that can help me optimize an InnoDB/MariaDB server. There are a few issues that the current server has that I would like someone to have a look at.
If you are interested send your resume and hourly and daily rate to innodb-application@cogito.website
Put PHPFreaks & InnoDB in the e-mail subject.
Thank you.

Okay, let's try something simpler. Say you have this code:
<?php
declare(strict_types=1);
// ..
public function setAge(int $age) {
$this->age = $age;
}
Passing a string to this method will throw an exception. The form processing code should validate that the age is indeed a number before passing it to your setAge() method. You can't start accepting "Dave", TRUE, ['foo']['bar'] = 'bat' as age. What I said above is basically the same thing. You protect your model from invalid data.
If the business you are writing this software for has other rules, like must be over the age of 18. Then you will need to add additional checks, that his rule is not broken. And this is where you use exceptions. To halt the code from polluting your model.
So to answer your question: yes, you must validate the data both in your model and in your form. The reasoning here is that your data might not always come from a form. But perhaps some data is input from a 3rd party API. Or from the CLI. Wherever the data comes from, you can be certain your model will always be valid. If you are too lazy to write out all the exceptions, follow these rules:
Use this library: https://github.com/webmozart/assert
Write custom value objects like the example in my previous post: BirthDate. Which you can use over and over again. Need another example?
<?php
class EmailAddress {
private $emailAddress;
public function __construct(string $emailAddress) {
if (!filter_var($emailAddress, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException(sprintf('The e-mail address "%s" is invalid.', $emailAddress));
}
$this->emailAddress = $emailAddress;
}
public function getMailTo(string $subject, string $body): string {
return sprintf('mailto:%s?%s', $this->emailAddress, http_build_query([
'subject' => $subject,
'body' => $body,
]));
}
public function getEmailAddress(): string {
return $this->emailAddress;
}
}
To answer your 2nd question:
Don't use exceptions for validation. The code should not be halted at that point, as you want to report back ALL errors at once to the user instead of 1-by-1.And use a format that is most easy to work with like an array to store the validation errors.
Also create dedicated validators for your entities. As you might need to validate your entity in more than 1 place. It can still extend from a base generic validator:
<?php
class LoginValidator extends Validator {
public function validate(array $data) {
return parent::validate($data, [
'username',
'password',
]);
}
}

Yes, your form and any other client-side code should have validation that checks that all business rules (being 18+) have been enforced.
Validation and exceptions are not the same thing. Validations are done before you pass it down. While exceptions are thrown after it has been passed down and is invalid.
Because your model sits at the center of your application and is guarded with exceptions it becomes impossible to use them with invalid data. Which makes your life as a developer much easier.
And anything you add on top adds it's own validation and has it's own method of communicating error's back to the user.

Entities should not have error messages, they should throw exception's on invalid input. Error messages are to indicate to the user that what he input is invalid.
Why exceptions? Because your model must be a source of truth, it enforces the business rules.
The application (forms, buttons, ui) lies on top of your model. So for the application to communicate effectively with the model it must ensure all input is valid BEFORE the model is called.
The exception's are usually called like this in the model:
<?php
public function setBirthDate(DateTimeInterface $dt) {
$this->assertGreaterThanOrEqualTo18($dt);
$this->assertLessThan100($dt);
$this->birthDate = $dt;
}
Because you may have these business rules. You can take it one step further:
<?php
class BirthDate {
private $date;
public function __construct(DateTimeInterface $date) {
$this->assertGreaterThanOrEqualTo18($date);
$this->assertLessThan100($date);
$this->date = $date;
}
}
public function setBirthDate(BirthDate $bd) {
$this->birthDate = $bd;
}
Now every time you use a birthdate you will apply the business rules.

If you have a monetary income in any officially recognized currency*, you need to pay tax! It's that simple, really. Now it's possible that certain income is exempt from tax, for example, a yearly turn-over less then 5.000 individually, or 25.000 as a business. That's the current law in Belgium.
I am not an accountant, and I am unfamiliar with tax regulations in Australia. If you have a business, it's recommended to have an accountant, he'll advise you on the best approach, and keep your taxes in check.
*So anything not monetary, or any unofficial currency, would be tax-free. Get paid in litecoin?

Admin seems more like a privilege/role, so I would make that a field of User.
Then your User and Person. I get what you are saying, and I have this in my system. I would have a Person object with no reference to a User. And let the User reference Person. Thus decoupling my application from the auth layer.
<?php
class User {
const ROLE_SYSTEM = 'role_system';
const ROLE_ADMIN = 'role_admin';
/**
* @var string[]
*/
private $roles = [ ];
/**
* @var Person|null
*/
private $person;
}
For system accounts, the Person reference would be NULL as it's not required and it's role would be ROLE_SYSTEM.

And after you started using the power sander, how often have you done it by hand since?
And if given the chance to do it by hand, would you still do it?
Regardless of the fact that these are apples and oranges. If done by hand or machine delivers about the same end-product. Regardless with which you started or ended. You can start by hand, go to the machine, and finish by hand. Also the work still has to be done, to get the final product.
This is not the case in software development. You would basically pick up an already sanded object of any length and any given size in an infinite supply.

Events are a good way to extend your code without adding unnecessary dependencies.
A ghost copy is a class with only it's ID filled in.
Personally I avoid writing things that have been written before and rather build upon them. In the long run of an application you get burned by the "not invented here" syndrome. I have seen it over and over, and over again.

What requinix said, and to reduce unnecessary: querying, hydrating, etc.. for what is essentially throwing something into the bin.
And it still allows your mapper to fire off any associated events, if there would be any.
Another option would be to use a ghost copy, and drop the deleteOneById. But that depends on how you architect your software.
Since a DELETE is the opposite of a SELECT. You can create any "query" methods for it:
deleteAllByCompanyName(string $companyName);
Internally they do the same thing as with the deleteOneById. They query and store any ID's scheduled for deletion. So that any future find's would return NULL even before the database is synchronised.
Avoid any createFromArray or updateFromArray methods though, use the find methods instead.