Display document titles in the Document Index table

Was done during the Nested Spaces sprint.

Thanks for the info. I agree that applications/components should have a way to provide their own safe named queries (without having to write HQL directly in Velocity scripts with PR), and my guess is that would happen through registering with or extending the Query Manager class in Java and exposing it to the script context. Is my understanding correct? (This might be a good candidate for a page in the Dev Guide.)

Hi Joshua,

Some info:

• Named queries already exist using the Query Manager
• If you're using groovy then you can use all APIs requiring Programming Rights, there's no need for a named query (which is by definition static).

I like the idea of having named queries, but could there be a way to build named queries without modifying the core? I suppose that would be something along the lines of a Groovy class which extends the query manager.

I don't agree that we shouldn't use HQL because we may want one day to move to JCR. We're already using HQL everywhere (we don't have a single query that is not HQL actually!). So if/when we move either we find a way to support HQL or more simply we'll rewrite the queries using the new query language, whatever it is.

Named query is interesting since it doesn't require any extra module. There's a way already which is to use the Query Manager. All we'd need is to bind it in the script context (and make sure only existing queries or safe queries can be executed).

I agree that for performance we should optimize as much as possible, and querying the database is a good way to improve performance. I had to do it for generating CSVs from thousands of documents, when loading documents simply was impossible.

But, doing HQLs is bad because it means that we'll never be able to move away from HQL into JCR, and we need to have pages with Programming Rights in the wiki. PR is bad, it's easy to find a way around them (I know I can), so one less page with PR is one less security concern.

So, the only conclusion that I can get from this is that we need an easy way for applications/components to provide their own named queries.

BTW re titles, we could do this:

• get the title from the DB in the single query
• for docs which have the title empty, check in the title cache
• if not in the cache, load the doc and compute the title (which is then put in the cache)

we try to depend as little as possible on HQL

Well that's definitely bad if we ever want a performant wiki... Caches help but are not the end solution and they have their limitations (you always need to load docs to populate them and they have max sizes).

And we can (and should) easily circumvent the issue of programming rights by using a fixed predefined query, as it's possible with the Query Manager, or probably even better by introducing a specific server-side API for returning doc data in a single query.

BTW in all performant apps I've ever written in the past we've never been able to do differently than having specific server-side APIs that matches specific UI needs (we called them services), in order to reduce the number of queries against the database. I don't see why it would be different here.

So we have 2 choices:

• Keep hitting the document cache in AllDocs. (btw this is bad since user can do searches and searches will hit docs not used frequently and thus filling the cache with not needed docs, thus evicting other frequently used docs).
• Try to fix performance issues by doing optimizations

I'm for the latter one.

This could be done with a single query against the database

Yes, with programming rights. That's not the way we usually do things, we try to depend as little as possible on HQL,

No there is no extra cost of displaying titles. We load all docs for the displayed page anyway

I don't understand why we need to load all documents in the livetable in order to display their name, date, author, etc. This could be done with a single query against the database, couldn't it?

Plus, the doc.displayTitle does not look in the document content, just the title field and the document name.

That's not the pb. As soon as you call getDispplayTitle you have already loaded the document since it's a method in the document class.

Re the title I persist in saying that it's costly. We could easily add a new column to the DOCS table in the DB but we'd have to agree that the title isn't computed anymore from the content. The other alternative suggested by sergiu some time ago is to have a title cache (even easier to do) since titles are not too long we could cache quite a lot of them (even if it still means loading the docs, which isn't perfect).