[Cosmo-dev] Results of Hibernate Propfind initial testing

[Brian Moseley]

On 9/2/06, Bobby Rullo <br at osafoundation.org> wrote:
> oh, I thought you guys had that one nailed by the time I checked it
> out. I was building from r922.

nope. the problem is that several of the properties for non-collection
resources (content length, type, encoding, language) are stored in
this separate attributes table. these properties are returned as part
of an "allprop" propfind response, the most common type of propfind,
so we load them whenever we materialize an item from the database.

even if we were to load properties on demand (thereby not hitting the
attributes table when we materialize the item), an allprop will force
us to turn around and load those properties above, which will cause
the separate queries against the attributes table for every item.

i think the solution is to store those four pieces of content item
data in the items table itself and to change DavResourceBase to only
load other properties when they're needed (by a targeted propfind, for
instance). this should get us down to a total of two sql queries for
your depth 1 propfind: one for the collection and one for its members.