more informative SearchView rows

[mfrasca]

from a comment to the discussion in #245 . is it difficult to do something like this?

[mfrasca]

@tmyersdn say we do it like this

the same question could apply to Accession, too. and in this case I would state <count> plants in <location name> only if all plants are in the same location, otherwise the text would be <count> plants in <count> locations. so the above 2014.0091 would show »5 plants in 2 locations«. but doing this for Accession would mean a database join (with plant and with location), and this would cost time.

[mfrasca]

or maybe just <count> plant groups in <count> location(s) ... I don't know, I'm afraid of slowing down the main screen but I have the impression this is useful information.

[mfrasca]

what does @RoDuth say about it?

[mfrasca]

what about this.

thinking of the reviewing of the threading code, I guess it's not such a problem if this takes a bit longer if this happens in a thread that will not block the user interface.

[mfrasca]

still doing what is possible without yet questioning what is wise:

note:

• after the name of the species, you see —thin— the authorship for the species epithet.
• if the species is considered synonym of an accepted name, show this too. (was marked as TODO in the code.)

[tmyersdn]

I like this, how about using a different colour for the synonym information to differentiate it? @RoDuth will definitely be feeling cluttered...

[mfrasca]

I always try to be careful with adopting colours. I feel they attract attention, that is distract. I prefer working with light/bold, grey/black, smaller/larger. I am not sure I like that purple for dead plants either!

[mfrasca]

I think this is complete so I close it, but you can always add comments and reopen if you think so.

[RoDuth]

Yep, its cluttered @tmyersdn @mfrasca !

But I can live with it... Can see the point... But no more!!! :laughing:

[mfrasca]

it is slowing down the interface. I think this is partially a consequence of something I consider a mistake in Bauble, regarding primary keys: in Bauble all tables have a numerical automatic primary key. means that if you want to get just any property from a linked table, even the value of the thing you would consider part of their unique identification parameters (the primary key), as it would be the location code, or accession code, you need use the numeric primary key to get to the linked table and get from there the desired code. so from plant I have a link to location in the form of location_id. consequence: I want to write <count> alive in <location.code>, Bauble has to join the two tables. I am considering, for the 1.1 version, to change this and to link things 'naturally' where possible. this would allow grabbing the code of a location directly from the plant referring to the location, simply because in the plant we would have a location_code field instead of the current abstract location_id.

[RoDuth]

I'm going back a long way now but when I was first looking at constructing a simple database for ourselves (prior to finding Bauble) I was warned off using any user set fields as primary keys by several botanic gardens database people that I spoke to at the time. e.g. a location code can change (we have done it ourselves a few times now! And on quite a large scale once I might add - we use our location codes in several ways...) Even an accession number may need to be changed on very rare occasions (normally due to some human error that is discovered at a late stage). Not sure how good this wisdom was but I was always told that using auto primary keys would avoid all kinds of headache in the long run. You'd know better than I would, it just made me remember about being given this advice.

As for the slowing down, I can't say I really notice the speed difference on my laptop. What I'm saying is that its more that it looks a little too busy which I always feel can distract the operator from their intended purpose and hence slow them down. Just a personal preference thing I guess. Think the Google home page v the Yahoo home page (flashing adds, weather reports, headlines, etc. etc., its just too much!). I think the balance you have come up with works fine so I'm not going to complain. Actually think I could come to like it!

[mfrasca]

ok, information from the field is useful! :+1: the speed loss could become invisible to the user when we complete stepping into threading from fibra. (#253)

[brettatoms]

Having an integer primary key is good database design and even in cases where it might not make as much sense (e.g. like a location code) it still might be worth keeping the integer primary key so that all the tables in the database have a consistent layout and naming scheme.

The speed difference in a SQL database for this join and getting the code is negligible. I don't have a current Bauble database to run this against but running a similar query against a database that's significantly larger than your average Bauble db shows a difference in just a few milliseconds.

We have a user_library_item table with 4+ million rows and a product table with 21k rows. The product table has a unique code similar to a location code. Selecting 1000 unique product codes directly from the table and selecting them with a join and a where condition on the library item table takes almost the same amount of time.

#  select p.ng_id from user_library_item l join product p on l.product_id = p.id where rating >= 4 limit 1000;
Time: 162.924 ms

# select p.ng_id from product p limit 1000;
Time: 156.191 ms

You will get more performance improvements with good indexes than working around the integer id.

Having a variable length string as the primary key could even potentially slow down queries where you have to use the code in a join (like getting all the product in a location) because you're potentially comparing 16 bit integers vs string matches which are 8 bits*length(code) (not exactly with indexing but still more potential for slow down than having an integer primary key).

[mfrasca]

I did not do measurements here (yet). the point raised by @RoDuth is most relevant, that his codes cannot be considered primary keys. enough of a no-go. indexes are meant to speed up search when primary keys can be complex, so good indexing sounds to me more in favour of having meaningful primary keys than against it. I'm observing that with SQLite and an i3 laptop, ~6 years old, the SearchView do feel slower now. not measured, just see that it's less responsive to scrolling to areas that have not yet been shown. but then again maybe with better threading it will not be noticeable any more, and anyway this is not going to be an issue on the http-based interface.