-
Notifications
You must be signed in to change notification settings - Fork 55
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
Convert the ORM #33
Comments
Repository fuelphp/orm created. |
If more than one orm object is returned by a query/find it could be worth wrapping the array in an object to allow for things like: <?php
$models = Model_Test::find('all', array(...));
$models->status = 'foobar';
$models->save(); This would then perform the action with a single quer. |
@stevewest this would work if the result object would be a collection which is model aware, I've done it a orm thingy I built 2 years back or so. It's quite handy, the only thing is that an model instance would need a backdoor to push the changes and update it's internals too. |
I think it would be a pretty tricky (read imposable) thing to do with the current codebase. It would be nice to do some refactoring on the ORM code to make it more extendible. If that work is done I can't see it being too hard to implement. I am not sure it would have to access a backdoor to the model if things like the table name and property names are available. Potentially it could be generated in a similar way to how Query objects are created. |
We have to be careful changing stuff that may impact BC too much, the transition to 2.0 should not mean a complete rewrite of your code. So we have to find a trade-off, and possibly postpone more radical changes to a later release. |
Of course, I was not thinking we would suddenly change the whole api for it. After working with the code for temporal and soft delete I found myself having to shoehorn my changes in around the existing code. A bit of internal clean-up would be beneficial, most of the main methods are pretty long and messy. |
Note to v2 requirements: Allow multiple relations on the same FK |
Functionality can stay as-is, Model interface might change, and the DB layer needs to be swapped for the new DBAL.
The text was updated successfully, but these errors were encountered: