Open GoogleCodeExporter opened 9 years ago
Verified with local dev setup.
Whether or not the table appears is independent of number of rows; a table with
2179034 rows loads quickly, whereas another with 363 rows never loads.
Original comment by scott.br...@gmail.com
on 11 Mar 2015 at 11:59
The issue here is that ORDS is trying to pull in the complete list of FK values
for every column and populate a drop-down list for each row.
In the case of Documents, this means that the linked ObjectID consists of
51,000 values. Ords then tries to make a drop-down with 51,000 items for each
of the 100 displayed document.objectid rows. A total of 51,000,000 option tags
:(
I removed the FK relation to Objects to test this was the problem, and indeed I
did then get a result eventually!
But even a relatively small FK like Locations results in 4000-long dropdowns x
100 rows = 400,000 option tags on the page. This also results in a page
download size of 26.5Mb just to get all the data needed to draw the page.
A solution is to stop offering option dropdowns for foreign key fields where
the number of distinct keys > 100. Instead provide a simple text box and
perform a lookup to check if the constraint is met when the user saves, or
perform an auto-complete.
After all, having 4000 dropdown options isn't exactly very usable.
For now I propose not returning the drop-down relation values at all for lists
longer than 100 and rendering a simple text input field. Better usability
options for FK fields should be a new feature request.
Original comment by scott.br...@gmail.com
on 11 Mar 2015 at 12:53
Thanks Scott, that sounds very sensible to me. Let's go with look-ups where
there are more than 100 distinct keys.
Original comment by jajwil...@gmail.com
on 11 Mar 2015 at 1:01
I've modified the way ORDS displays tables, only displaying select lists for
small reference sets (100 or less distinct identifiers). For larger reference
sets it just shows the referenced value in a text box instead.
In my tests with OxRep this reduced page load from 28Mb to 900k (which is still
too big IMHO, but much better).
Some existing behaviour is broken by this fix, as described in issue 631.
Original comment by scott.br...@gmail.com
on 11 Mar 2015 at 3:02
Original issue reported on code.google.com by
jajwil...@gmail.com
on 11 Mar 2015 at 10:50