testdriver_mt problem: caching and validation of docs

Bug #867238 reported by Markos Zaharioudakis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zorba
New
Medium
Chris Hillery

Bug Description

Currently, testdriver_mt will use a cached doc as is, i.e., without trying to validated if validation is required and without reloading the doc if it is validated but the query needs a non-validated version. It will also unconditionally validate a doc that is loaded for the first time. This behaviour causes close to 100 tests fail in my (and Matthias') local build. These tests succeed if run individually (e.g., by testdriver). For example, one query will load and validate a doc, and then another query that does import any schemas will fail because it tries to access this doc, but it does not understand the (user-defined) types of its nodes.

This problem exists since the DynamicContext::setVariableAsDocument() method were removed from the C++ API.

I have made a temporary fix, by basically disabling caching: if a query finds the doc in the store, it deletes it and reloads it.

I think the fix should be the the following :

1. Extract info from the XQTS catalog about whether validation is required or not (I am not 100% sure, but I believe the info is there).
2. If loading for the 1st time, validate the doc only if it is required by the query that does the loading.
3. If doc is loaded already:
3.1 If it is validated, delete it and load it again (validating if necessary, i.e., if required by the query)
3.2 If is not validated, validate if necessary

This implies that we need to add an isValidated() method to the DocumentManager api.

Revision history for this message
Matthias Brantner (matthias-brantner) wrote :

temporarily fixed in rev. 11986

Revision history for this message
Markos Zaharioudakis (markos-za) wrote :

I wouldn't mark it as fixed. I didn't give it a higher priority because of the temporary fix, but a real fix should be provided eventually. Marking it a "fixed" is a small step before moving to the "closed" status and to final oblivion. Notice also that bug #3349286 was marked "closed" at some point although it shouldn't have been (but it is ok to have that one closed now, because of the temporary fix).

Chris Hillery (ceejatec)
tags: removed: v2.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.