Landing pages and search results should display Title, not Uniform Title about autocat3 HOT 10 CLOSED

I've looked at fixing this before. The issue is the titles are stored in the attributes table and can't really be returned with the author query as the uniform title can be (maybe they can, but I'd sooner re-write the pages using ORM code and take some performance hit). So instead of a single query, an additional query must be made for every title returned. The usual ways for highly trafficked websites to deal with this are: to add a field to the books table; to populate the results asynchronously; or to shard or beef up the database. Now it may well be that the relevant result pages are small and infrequent, so performance doesn't matter - if we extract some numbers from the logs this would help inform the development work, but in any case this would need re-writing a page and load testing - a couple days of work.

from autocat3.

from autocat3.

So you realize that switching the display will result in a ridiculous-looking alphabetization? And switching the field used for alphabetization will cause complaints about sorting "The Aristocrats" under "T" instead of "A". I don't think you can win here.

from autocat3.

Yesterday:
7430 | 0.20% | 0.02 |   | /ebooks/authors/search/

so about 5 author searches a minute

from autocat3.

from autocat3.

OK, I looked at this again. The title sort was not what I thought.

Here's the function that creates the title for sorting:

`    SELECT ltrim (substring (attributes.text FROM attributes.nonfiling))
       FROM attributes
       WHERE attributes.fk_books = $1
       AND attributes.fk_attriblist = ANY (ARRAY[240, 245, 246])
       ORDER BY attributes.fk_attriblist
       LIMIT 1;
`

so Uniform title (240) is used when it exists, just because 240 < 245 !

It's in the SQL Schema. So this has nothing to do with Autocat3! It should be trivial to change for someone familiar with Postgres SQL, and then somehow rebuild the database.

Closing the issue because it can't be addressed with anything in the repo. Probably would be a good idea to put the database schema in a new repo.

from autocat3.

The cited SQL code is part of autocat3, so I'd rather leave this issue open. We can tag it "won't fix" for now.

I'll try to get support in adjusting the SQL, or refactoring the database. I think we just need a slightly more sophisticated query.

from autocat3.

No, it's not part of autocat3. It might possibly be part of the cataloguing tool. The right way to fix this is to change the schema, most likely that's not been committed anywhere. Our query is fine. I know of someone who might be willing to help.

from autocat3.

I will create a repo for the sql

from autocat3.

fix applied to production

from autocat3.