Can't view certain tables in the OxRep database

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Upload the OxRep database to App 1.0.9.
2. Try to access the 'Coordinates', 'Documents', or 'Biblioref' tables in the 
data editing page
3. Note that the screen never gets beyond the 'Loading table data' message.

What is the expected output? What do you see instead?
Given that other much larger tables in the same db open without any problems it 
seems that there is something about the way in which the data in these tables 
has uploaded that is confusing the system confusion. Scott has a copy of the 
original SQL dump, which may hold clues.

Please use labels and text to provide additional information.
Chrome App 1.0.9

Original issue reported on code.google.com by jajwil...@gmail.com on 11 Mar 2015 at 10:50

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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