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

reset so that we can call find_many after count #97

Closed
wants to merge 1 commit into from

Conversation

fayland
Copy link
Contributor

@fayland fayland commented Jan 24, 2013

Hi

it's a very common case.

we use

$orm = ORM::for_table('table');

// then we build complicated where.

then we count first

$total = $orm->count();

if total > 0, we then select with a limit.

$xxx = $orm->limit(50)->offset(10)->find_many();

or we call find_many first, then we call count on those build complicated where.

the patch will reset the _values and _result_columns so that the case will work. right now it is broken because the _values will be pushed twice. and COUNT(*) will stay on find_many.

Thanks.

@windbridges
Copy link

I think it will better to add support for SQL_CALC_FOUND_ROWS and FOUND_ROWS() instead.

@fayland
Copy link
Contributor Author

fayland commented Jan 24, 2013

but it's a common fix and it's suitable for max min etc. too

the big point here is that it does not harm anything I think.

Thanks

@treffynnon
Copy link
Collaborator

@windbridges that is a neat solution for MySQL, but it isn't portable to Postgres or SQLite for instance. I use a customised version of Idiorm that does just this for a number of projects - perhaps it is something that might end up in Idiorm in the future, but I haven't had time to give it enough thought at the moment.

@fayland what advantage is this giving you over just calling for_table again besides reducing typing?

@fayland
Copy link
Contributor Author

fayland commented Jan 24, 2013

@treffynnon Note I may build very complicated where before count.

if we do not have that, I need rebuild those complicated where again.

for example:

$orm = ORM::for_table('table');

if (1) $orm->where('hello', 'world');
if (2) $orm->where_gt('six', 6);

$total = $orm->count();
$rows = $orm->limit(5)->offset(10)->find_many();
$max = $orm->max('x');

the patch here supports that you do not need rewrite those where again.

Thanks

@treffynnon
Copy link
Collaborator

That is what I had suspected. It is a known issue with Idiorm that you can't fork queries like you are suggesting here and it is something that is going to be addressed in the future.

For now I cannot see any reason not to merge this fix, but I will need to test it against the code currently in the develop branch.

@ghost ghost assigned treffynnon Jan 24, 2013
@treffynnon
Copy link
Collaborator

Merged in commit 9f9fd4d

@treffynnon treffynnon closed this Jan 29, 2013
@mapner
Copy link
Contributor

mapner commented Jan 31, 2013

I use:

$orm = ORM::for_table('table');

$orm->where('hello', 'world');

$cntorm = clone $orm;

$total = $cntorm->count();
$rows = $orm->limit(5)->offset(10)->find_many();

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

Successfully merging this pull request may close these issues.

None yet

4 participants