-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Comments
This is already in plans after v6 completion. Moving into |
@noone-silent There is some work already been done but very early days on this. Check the Believe me, we share the sentiment. |
Do you have some structured plan? Like an UML or something? I would be happy to help in progressing Phalcon 6 |
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
andarray
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
getRelated
withgetOne
andgetMany
.Complex
andarray
are no solutions. If you have requests like that, you should use thedb
service directly. That is not what ORM is for.__set
and__get
. Nobody want to work withmixed
type anymore!__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 7The text was updated successfully, but these errors were encountered: