There is some more discussion here:
http://framework.zend.com/issues/browse/ZF-7666
I'd follow up on that thread.
The problem is that LIMIT is not an SQL standard, and there is no
standard approach.
http://troels.arvin.dk/db/rdbms/#select-limit
As such, our API in ZF1 needs to remain as consistent for possible for
the main API.
What I fail to see is why this cannot be implemented in userland?
Instead of:
$select->from()-> .... ->limit($limit);
You dont just use:
$select->from()-> ....;
if (is_int($limit) && $limit > 0) {
$select->limit(0);
}
Doesn't that (semantically) make more sense?
-ralph
On 10/4/10 9:43 AM, Daniel Latter wrote:
not yet, will do later.
Daniel
On 4 October 2010 15:42, Hector Virgen<djvir...@gmail.com> wrote:
I agree; iterating over a "limit 0" result set should result in no more
than 0 iterations. Have you filed a bug report?
--
Hector Virgen
Sent from my Droid X
On Oct 4, 2010 2:17 AM, "Daniel Latter"<dan.lat...@gmail.com> wrote:
what i meant was if you do happen to pass a zero to the limit method,
then
say loop over the (possibly millions of rows it will return) returned
rows,
couldn't this potentially bring down a server?
Daniel.
2010/10/3 Valeriy Yatsko<d...@design.ru>
Good day
Yes, but it doesnt seem right to assume someones app will have the
same
amount or rows that is equesl to the max integer the os can hold?
You really have table larger than 2 000 000 000 entries on 32-bit
servers?
:)
Let's see... int = 4 bytes on 32 bit systems:
2 000 000 000 x 4 = 8 000 000 000 = ~ 8 gb minimum per table :)
Let's add here at least varchar(255):
2 000 000 000 x (4 + 255) = 518 000 000 000 = ~ 518 gb per table :)
Try to search some data through this table. :)
There are some architecture solutions for this, like splitting tables
into
smaller (or shards).
--
Валерий Яцко
______________________________________________________________________
d...@design.ru | http://www.artlebedev.ru
