Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NFR]: Complete rework of ORM #390

Open
noone-silent opened this issue Sep 11, 2023 · 3 comments
Open

[NFR]: Complete rework of ORM #390

noone-silent opened this issue Sep 11, 2023 · 3 comments
Labels
new feature request Planned Feature or New Feature Request

Comments

@noone-silent
Copy link

Is your feature request related to a problem? Please describe.
The ORM was edited a lot over the years and is unbearable anymore. Every few weeks, new bugs are discovered. Some are ground breaking (save all related records, event they did not change. reusable aren't reusable... and many more), some not. New features get implemented and create new bugs. Also PHP will be more and more type safe and the ORM is nothing of that. For example getRelated returns: null, false, Simple, Complex and array
To write valid modern type safe code, you would have to check on all of this and make sure YOUR type is the one you actually need.
There is too much magic happening and it feels like everyone is losing control about it. You touch one thing and another thing breaks. We should go back to the roots and make the ORM plain and simple for normal days of work.

Describe the solution you'd like

  1. Less magic. ORM should be predictable
  2. Replace magic methods like getRelated with getOne and getMany. Complex and array are no solutions. If you have requests like that, you should use the db service directly. That is not what ORM is for.
  3. Disallow any magic via __set and __get. Nobody want to work with mixed type anymore!
  4. Do the work, but keep it simple and testable.
  5. Make it pluggable. If someone needs some type of magic or anything else, they can have it without making every ones code suffer from it. You want __set and __get back? Here is you plugin for that.

I'm not sure if this should be started as an incubator project or still implemented in zephir. Phalcon 6 is still far away and even then, the C extension will still be there. Maybe we should create a new namespace below \Phalcon\Mvc\Model like \Phalcon\Mvc\Model\Light or directly start with a new namespace like \Phalcon\Orm. So everyone could use the old bugged Models and the new and robust one, would be somewhere else. Then with Phalcon 6 we could deprecate the Model for Phalcon 7

@noone-silent noone-silent added the new feature request Planned Feature or New Feature Request label Sep 11, 2023
@Jeckerson
Copy link
Member

This is already in plans after v6 completion.

Moving into phalcon/phalcon.

@Jeckerson Jeckerson transferred this issue from phalcon/cphalcon Sep 11, 2023
@niden
Copy link
Sponsor Member

niden commented Sep 11, 2023

@noone-silent There is some work already been done but very early days on this. Check the DataMapper folder. The PDO connection is there along with a query builder. After that we have to add the information/metadata classes, table mapper, data mapper.

Believe me, we share the sentiment.

@noone-silent
Copy link
Author

Do you have some structured plan? Like an UML or something? I would be happy to help in progressing Phalcon 6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature request Planned Feature or New Feature Request
Projects
None yet
Development

No branches or pull requests

3 participants