[email protected] wrote:
> Examining an app created with the dabo AppWizard, we noticed that "Show
> SQL" menu option displays SQL that includes a limit clause (limit 1000).
Added by default by the datanav select page (ui). Look at the select
page, there's a place to set the limit right there.
> I checked the bizobj in the bz directory, and there is a
> self.setLimitClause("500") there. A note indicates that the UI might modify
> this, and
> apparently it has, changing it to 1000.
I purposely made one 500 and the other 1000 to make people like you
scratch your beard and go "hmmm...." :)
> Am I right in assuming that we have control over whether to use a limit
> clause in the bizobj, and that it is not automatically added to the SQL?
I honestly can't remember if you can remove the limit clause completely,
but you could set it to a huge number. You should keep a sane limit
though: if you need thousands of records locally you probably need to
look at your design. Of course there are exceptions to this though.
> Second question is, using a Client-Server backend like MySQL, are there any
> issues (performance or other) that make using a limit clause desirable? If
> I create a grid that's mapped to a large table without a limit clause in
> the bizobj, will there be problems?
The grid won't have trouble, but the db layer of dabo makes a copy of
every row returned by the dbapi adapter, and it uses fetchall() instead
of fetchone() or fetchmany() so as the number of rows in the result set
go up, requery speed will go down.
But no, there's nothing in MySQL that would make a non-limited select
take longer, other than it will be returning more rows which will
decrease performance.
> Third question is, if there is a limit clause, what happens when you push
> to the bottom of your set of 1000 in the grid. Does the bizobj handle
> getting the next 1000?
No. Different database backends offer "paging" in different ways, and we
make no attempt to handle that in the data layer.
The best general design is to get smallish result sets from the backend.
> (I figured I'd ask while I try to generate enough records in my table to
> try this!)
Best way is to try for yourself. I have a module in my app that
requeries thousands of rows, and it performs fine.
Use bizobj parent/child relations, so that child bizobjs only requery
the rows that match the parent, instead of getting all rows from child
bizobjs. And as a rule, try to limit the parent requery by giving date
ranges, search criteria, etc.
The limit clause is mostly there as a protection against a user
unknowingly preparing a 'select * from customers' query against a remote
table with a million rows.
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
