This code ensures we get integers, but we can still get SQL errors if one
of these values is negative.
If we prevented negative numbers for these values (with something like the
following), we would prevent this type of SQL error and I think still
support all valid use cases:
> This code ensures we get integers, but we can still get SQL errors if one of
> these values is negative.
> If we prevented negative numbers for these values (with something like the
> following), we would prevent this type of SQL error and I think still
> support all valid use cases:
> > This code ensures we get integers, but we can still get SQL errors if
> one of
> > these values is negative.
> > If we prevented negative numbers for these values (with something like
> the
> > following), we would prevent this type of SQL error and I think still
> > support all valid use cases:
Il giorno 02/mag/2012, alle ore 06:51, Chris Davenport <chris.davenp...@joomla.org> ha scritto:
> $this->limit = abs( (int) $limit );
> Avoiding the conditional?
> Chris.
It's a better solution.
Just a proposal: each driver has to manage and format these values in different manner inside it's own query, so why don't add "limit" and "offset" inside JDatabaseElement, as I already did inside Postgresql's driver, for 3.0 or 3.5 release ?
Eng. Gabriele Pongelli
AVVERTENZE AI SENSI DEL D.LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservati. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse.
This electronic transmission is strictly confidential and intended solely for the addresses. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us and delete the received data as soon as possible
> Just a proposal: each driver has to manage and format these values in different manner inside it's own query, so why don't add "limit" and "offset" inside JDatabaseElement, as I already did inside Postgresql's driver, for 3.0 or 3.5 release ?
+1
It's fine for SELECT ... LIMIT OFFSET syntax to just append to the SQL, but for other syntax it all gets a bit hacky[1] trying to rewrite the query, which naturally involves making some assumptions.
> This code ensures we get integers, but we can still get SQL errors if one > of these values is negative.
> If we prevented negative numbers for these values (with something like the > following), we would prevent this type of SQL error and I think still > support all valid use cases:
On Wed, May 2, 2012 at 9:06 AM, Ian <ianlen...@gmail.com> wrote:
> I'm inclined to think that if $limit or $offset is less than 0 you throw
> an InvalidArgument exception.
> Ian
> On Tuesday, 1 May 2012 19:54:57 UTC-4, Mark Dexter wrote:
>> In the setQuery() method we have the following code:
>> This code ensures we get integers, but we can still get SQL errors if one
>> of these values is negative.
>> If we prevented negative numbers for these values (with something like
>> the following), we would prevent this type of SQL error and I think still
>> support all valid use cases:
What if the input is not an integer? Currently we are converting to
integer. Should we throw an exception also if either value is a
non-integer? Thanks. Mark
> What if the input is not an integer? Currently we are converting to
> integer. Should we throw an exception also if either value is a
> non-integer? Thanks. Mark
Although I think that casting is acceptable, an Exception would be the
cleaner way, which I would prefer.
Good point, Mark. I guess the question is - what is the API in this case?
If it's not clear, then maybe deciding what input is required is the first
step. Certainly makes it easier to code with those decisions in place.
On Wed, May 2, 2012 at 10:08 AM, Mark Dexter <dextercow...@gmail.com> wrote:
> What if the input is not an integer? Currently we are converting to
> integer. Should we throw an exception also if either value is a
> non-integer? Thanks. Mark
> On Wed, May 2, 2012 at 7:02 AM, Niels Braczek <nbrac...@bsds.de> wrote:
>> Am 02.05.2012 16:06, schrieb Ian:
>> > I'm inclined to think that if $limit or $offset is less than 0 you
>> throw an
>> > InvalidArgument exception.
>> That's much cleaner than producing unpredictable[tm] results by
>> manipulating the input data.
using abs() will create a very different result than what Mark suggested
$limit = -5;
$this->limit = abs( (int) $limit )
= 5
this will clamp negative numbers to Zero which seems more safe to me
$limit = -5;
$this->limit = ((int) $limit >= 0) ? (int) $limit : 0;
= 0;
To avoid the explicit condition, the repetitive type conversion and
clamp negative numbers to zero:
$limit = -5;
$this->limit = (int) max(0, $limit);
= 0
