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

Convert the ORM #33

Open
WanWizard opened this issue Mar 8, 2013 · 7 comments
Open

Convert the ORM #33

WanWizard opened this issue Mar 8, 2013 · 7 comments

Comments

@WanWizard
Copy link
Contributor

Functionality can stay as-is, Model interface might change, and the DB layer needs to be swapped for the new DBAL.

@WanWizard
Copy link
Contributor Author

Repository fuelphp/orm created.

@emlynwest
Copy link
Contributor

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.

@frankdejonge
Copy link
Contributor

@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.

@emlynwest
Copy link
Contributor

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.

@WanWizard
Copy link
Contributor Author

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.

@emlynwest
Copy link
Contributor

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.

@emlynwest
Copy link
Contributor

Note to v2 requirements: Allow multiple relations on the same FK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants