Documentation Request

[Insolita]

I'll just describe here the most obscure points

• Since 5.5 Repository was marked as deprecated, what is alternative - full custom realizations with mapper injection, or something else?
• Accordingly https://github.com/analogueorm/analogue/issues/142 there is ability to map entity attributes to column names - what about similar behavior for properties?
• Example for transactions
• Example for incremental/decremental operations ( with queries like UPDATE table SET "foo"="foo"+1)
• Pros and cons for embedded objects instead of classic valueObjects via getters and setters

  // ...
  public function setStatus(StatusObject $status){
       $this->status = $status->getValue();
       $this->code = $status->getCode();
  }
  public function getStatus():StatusObject{
       return new StatusObject($this->status, $this->code);
  }

Of course, embedded objects are resolved automatically, but in some cases they can bring overhead?

[RemiCollin]

Noted!

Quickly Aabout repositories, I felt that they should belong to the application layer, and that the package should not be opinionated on their implementation. Also using repositories is totally up to the user, and mostly depends on application design choices, thus the deprecation

[quetzyg]

Totally agree with @RemiCollin. The user should be responsible for creating the repositories (if they see fit).

[Insolita]

I also agree. First, each repository should have the correct phpdoc type hints for the find * methods and we were forced to override the parent methods for convenient work. Anyone can write generator with core methods