db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <se...@backstagetech.com.au>
Subject Re: LargeSelect and databases which do not support native limit/offset
Date Mon, 12 Sep 2005 00:49:13 GMT
Thomas Fischer wrote:

> Hi,
>
> As was explained in http://issues.apache.org/scarab/issues/id/TRQS318,
> LargeSelect has a very poor performance for databases with no native
> limit/offset. I lookead at the code myself and also am of the opinion
> that using LargesSelect makes no sense if the db does not support
> native limit/offset.
>
> Therefore I am inclined to follow the proposed solution and throw an
> exception in the constructor of LargeSelect if the chosen DB does not
> support native limit and offset. The code would look loke:
>
>     private void init(Criteria criteria, int pageSize, int
>                       memoryLimitPages)
>             throws IllegalArgumentException
>     {
>         ...
>
>         {
>             String dbName = criteria.getDbName();
>             if (dbName == null)
>             {
>                 dbName = Torque.getDefaultDB();
>             }
>             if (dbName == null)
>             {
>                 throw new RuntimeException(
>                         "Torque is not initialized yet");
>             }
>             DB db;
>             try
>             {
>                 db = Torque.getDB(dbName);
>             }
>             catch (TorqueException e)
>             {
>                 throw new RuntimeException(
>                         "cannot retieve Database for DB name " + dbName);
>             }
>             if (db.getLimitStyle() == DB.LIMIT_STYLE_NONE)
>             {
>                 throw new IllegalArgumentException(
>                         "criteria must have a db which supports "
>                         + "native Limit and Offset");
>             }
>         }
>
>         ...
>
> Are there any objections ? Is everybody ok with throwing a
> RuntimeException, or would it be better to add the TorqueException to
> the throws clause, possibly breaking people's code because
> TorqueException is not caught ?

My only comment would be that as a heavy user of LargeSelect, if I were
to ever switch to a database that did not support limit and offset I
could not easily produce an executing (though obviously poorly
performing when it comes to LargeSelect) version of my application.

I would prefer us to add an appropriately worded statement in the docs
and javadocs highlighting the issue with a recommendation that it not be
used for the affected databases.

>
> I would also guess that the problems with databases which do not
> support native limit/offset have lead to the exclusion of the
> LargeSelectTest from the runtimetest. Does anybody object to include
> the LargeSelectTest and print an error but not execute the test if the
> database dose not support native limit/offset ? Sample code would be
>
> public class LargeSelectTest extends BaseRuntimeTestCase
> {
>     ....
>
>     public void testLargeSelect() throws TorqueException
>     {
>         if (Torque.getDB(Torque.getDefaultDB()).getLimitStyle()
>                 == DB.LIMIT_STYLE_NONE)
>         {
>             log.error("LargeSelect is known not to work for databases "
>                     + "which do not support native limit/offset");
>             return;
>         }
>
>     ....
>
> If one adds this, the LargeSelectTest also runs for hsqldb which does
> not support native limit/offset.

Does the test case fail at present?  If we continue to let the code code
execute for the reason given above then the test case should at least be
enabled to make sure that the simulated limit and offset are indeed
compatible with the behaviour when the database supports them.

Scott

-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message