-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Model::delete method #865
Comments
That's a fair point. Most of came simply from a base model I had used for years. I would create multiple small methods to handle specialized cases in each model so it was more readable, so the With the current model, though, you can access all of the Builder methods in your method chain, as well as the model methods, so it might make more sense to remove |
I think the delete should act like update/where clauses. I've been using the models myself and find it confusing why I can't do |
@timothymarois I think Looking back over the model methods, it might make sense to make these changes:
I think it would be tricky to reliably determine between an array of ids (which might be strings, also) and would stay consistent with the I'm tempted to say we get rid of |
@lonnieezell Yeah You're right, I used a version before which reminded me I had As for the As for delete, I really am for a delete method being used for batch deleting based on where clause. Honestly, this is how I believe // simple update
$db->update($id, $array);
// batch id update
$db->update([1,2,3], $array);
// update based on where (as the first argument states which items it needs to update)
$db->update(['status'=>'pending'], ['status'=>'active']);
// simple delete
$db->delete($id);
// batch id delete
$db->delete([1,2,3]);
// delete based on where (as the argument states which items it needs to delete)
$db->delete(['status'=>'pending']); These are my thought as to how I think they should work. I know most likely it's too late to really rethink how the model works. But I've always viewed it in this way because it makes the most sense and my intentions for using them. But you can correct me if there are some flaws in that. |
We're not even to a beta-release, yet, so it's not too late :) I like the simplification of what you've presented. I'm a little concerned that things get confused here. That one method now allows 3 ways to do things. The first two of them make sense and are close in functionality, but adding the third method muddies the usage. While it's simpler in some aspects, doesn't it make it a little less explicit about what it's doing? It's a bit more clear that I realize I'm might be getting a little far in the weeds thinking about this one, so I'm definitely interested in other opinions on this. @daylightstudio @jim-parry what's your thoughts? |
I could be misunderstanding PHP, but aren't I can see enhancing the existing delete to accept an array of ids. In the conversation earlier, there was a suggestion of method chaining, eg ->where(...)->delete(). This makes most sense to me, with similar changes to update(). In other words, enhance delete() and update() to work on the current "selection". |
@jim-parry Well, they are 2 different forms of arrays so they could technically be checked for but that seems like it might be easy to miss some edge cases. One form would always have numeric keys while the other may/may not. Seems a bit fragile to me. |
My opinion on the |
There is no end to it :-/ |
@jim-parry @lonnieezell I do agree that chaining a You should be able to do
|
I think we have all come to more or less the same decision. Sounds good. So, to sum up:
|
+1 |
@lonnieezell Agreed. I like the direction. |
@lonnieezell Also let me know if you need any help, I know we both have been working a lot these days. If I can get my development env set back up for CI, I might be willing to make a few of these changes if you think it will be a while before you can get to them. |
If you’ve got the time I’d say go for it. Knee deep in an outside of work project currently so time is definitely hard to come by for bigger changes right now. |
I'm curious why the Model::delete method is setup to only take an $id and and then there is a separate Model::deleteWhere? If Model::delete was more generic I think it could accommodate more conditions. As it stands now, the Model class needs to be extended to create your own "deleteOrWhere" and "deleteWhereIn" methods.
Thanks for all your hard work!
The text was updated successfully, but these errors were encountered: