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

[5.3] Return collections from the query builder #10552

Merged
merged 2 commits into from Feb 19, 2016

Conversation

Projects
None yet
6 participants
@JosephSilber
Contributor

JosephSilber commented Oct 11, 2015

As discussed in #10478

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Nov 10, 2015

Member

Going to hold off on this. DB::select returns an array and the query builder is just a light wrapper around PDO queries, so it's sensible for it to return arrays and we shouldn't feel obligated to make it return Collections just because the ORM does.

Member

taylorotwell commented Nov 10, 2015

Going to hold off on this. DB::select returns an array and the query builder is just a light wrapper around PDO queries, so it's sensible for it to return arrays and we shouldn't feel obligated to make it return Collections just because the ORM does.

@taylorotwell taylorotwell reopened this Nov 10, 2015

@taylorotwell taylorotwell changed the title from [5.2] Return collections from the query builder to [5.3] Return collections from the query builder Nov 10, 2015

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell Nov 10, 2015

Member

We'll aim for making this change in 5.3, which will allow us to put a deprecation notice in the 5.2 deprecation notes that get on query builder will start returning a collection. That will give everyone a full 6 months notice at least that they need to accomodate this.

Member

taylorotwell commented Nov 10, 2015

We'll aim for making this change in 5.3, which will allow us to put a deprecation notice in the 5.2 deprecation notes that get on query builder will start returning a collection. That will give everyone a full 6 months notice at least that they need to accomodate this.

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Dec 25, 2015

Member

Looking pretty nice to me. 👍 🚀

Member

GrahamCampbell commented Dec 25, 2015

Looking pretty nice to me. 👍 🚀

@JesseLeite

This comment has been minimized.

Show comment
Hide comment
@JesseLeite

JesseLeite Jan 29, 2016

Contributor

We'll aim for making this change in 5.3, which will allow us to put a deprecation notice in the 5.2 deprecation notes that get on query builder will start returning a collection. That will give everyone a full 6 months notice at least that they need to accomodate this.

@taylorotwell Is this still a thing for 5.3?

Contributor

JesseLeite commented Jan 29, 2016

We'll aim for making this change in 5.3, which will allow us to put a deprecation notice in the 5.2 deprecation notes that get on query builder will start returning a collection. That will give everyone a full 6 months notice at least that they need to accomodate this.

@taylorotwell Is this still a thing for 5.3?

taylorotwell added a commit that referenced this pull request Feb 19, 2016

Merge pull request #10552 from JosephSilber/qb-collection
[5.3] Return collections from the query builder

@taylorotwell taylorotwell merged commit e87e4a5 into laravel:master Feb 19, 2016

2 checks passed

StyleCI The StyleCI analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@JosephSilber JosephSilber deleted the JosephSilber:qb-collection branch Feb 19, 2016

@acasar

This comment has been minimized.

Show comment
Hide comment
@acasar

acasar Feb 19, 2016

Contributor

@JosephSilber @taylorotwell Can we make a helper method so that we can just call ->all() instead of ->get()->all() if we want an array?

Contributor

acasar commented Feb 19, 2016

@JosephSilber @taylorotwell Can we make a helper method so that we can just call ->all() instead of ->get()->all() if we want an array?

@JosephSilber

This comment has been minimized.

Show comment
Hide comment
@JosephSilber

JosephSilber Feb 19, 2016

Contributor

I personally don't think we need one, but if we do it should definitely not be all.

Maybe asArray or something. But meh.

Contributor

JosephSilber commented Feb 19, 2016

I personally don't think we need one, but if we do it should definitely not be all.

Maybe asArray or something. But meh.

@acasar

This comment has been minimized.

Show comment
Hide comment
@acasar

acasar Feb 19, 2016

Contributor

Nah, that's too long imo. I'm either all or nothing :)

Of course in that case we'd also need to update Eloquent builder so that all wouldn't return an array.

Contributor

acasar commented Feb 19, 2016

Nah, that's too long imo. I'm either all or nothing :)

Of course in that case we'd also need to update Eloquent builder so that all wouldn't return an array.

@JosephSilber

This comment has been minimized.

Show comment
Hide comment
@JosephSilber

JosephSilber Feb 19, 2016

Contributor
Contributor

JosephSilber commented Feb 19, 2016

@acasar

This comment has been minimized.

Show comment
Hide comment
@acasar

acasar Feb 19, 2016

Contributor

Exactly. If we do this, it should be added as an alias of get() because it will otherwise propagate to the QueryBuilder and we'd have inconsistent behaviour: User::all() vs. User::where(...)->all()

Contributor

acasar commented Feb 19, 2016

Exactly. If we do this, it should be added as an alias of get() because it will otherwise propagate to the QueryBuilder and we'd have inconsistent behaviour: User::all() vs. User::where(...)->all()

@JosephSilber

This comment has been minimized.

Show comment
Hide comment
@JosephSilber

JosephSilber Feb 19, 2016

Contributor

Which would be counter to everything we're trying to accomplish here. We'll once again end up with identical methods that return different types.

How often do you need an array that you want a separate method for that?

Contributor

JosephSilber commented Feb 19, 2016

Which would be counter to everything we're trying to accomplish here. We'll once again end up with identical methods that return different types.

How often do you need an array that you want a separate method for that?

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Feb 19, 2016

Member

I agree this is unneeded. It's only encourage people to not upgrade properly.

Member

GrahamCampbell commented Feb 19, 2016

I agree this is unneeded. It's only encourage people to not upgrade properly.

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