Hi, 5.0-4 does not solve this issue (although it solves a number of other issues).
I've logged a support ticket, and MarkLogic have been able to recreate this behaviour, so it looks real! :) Support have raised Bug 19722 - “Schema validation failing intermittently” Seems to be that when an existing schema is updated in the Schema's database, this may cause the database to mix-up or loose track of schema types; the only way I've found to reliably fix this is to clear the Schemas database completely, and re-load it. Ellis. On 3 Oct 2012, at 12:36, Ellis Pritchard <[email protected]> wrote: > Hi Mike, > > Thanks for the reply. > > The same Schemas database is configured everywhere, and I've re-checked that > our schemas validate. > > We'll give 5.0-4 a spin, it seems that the release notes aren't out yet, but > I've just heard that there are a number of (serious) problems fixed in 5.0-4 > related to a number of tickets raised by other people in our team... > > Ellis. > > > On 2 Oct 2012, at 18:46, Michael Blakeley <[email protected]> wrote: > >> The first behavior could mean that the Schemas database isn't configured the >> same everywhere. So I would start by checking that the content database has >> the right schemas database in each environment, and validate the contents of >> the database. >> >> I've seen something like the XDMP-LEXVAL behavior was when my schema was >> incorrect. I found the error by validating the schema itself. Fixing the >> error fixed the problem. >> >> I don't know if any schema-related bugs were fixed in 5.0-4, but that is >> worth trying too: >> http://developer.marklogic.com/products/marklogic-server/5.0 >> >> -- Mike >> >> On 2 Oct 2012, at 02:27 , Ellis Pritchard wrote: >> >>> Hi, >>> >>> We're experiencing some strange behaviour with Schema types (MarkLogic >>> 5.0-3.1, Linux & MacOS X). >>> >>> This manifests itself as a failure to enforce or correctly apply simple >>> data-types, and differs between databases loaded with exactly the same >>> schema and documents; all the schema's validate and are present. >>> >>> e.g. in one database, where Schemas appear to be working as expected, the >>> following correctly throws a XDMP-NONMIXEDCOMPLEXCONT exception: >>> >>> fn:data(element r:RaceRef { element r:UUIDRef { >>> '11111111-1111-1111-1111-111111111111'} }) >>> >>> this occurs because RaceRef is an xsi:choice and may contain either the >>> simpleType element UUIDRef, or a complexType element containing, er, mixed >>> complex content! >>> >>> On another database, where Schemas seem to be broken, this passes without >>> exception, which is troublesome not least of all because it differs, >>> apparently randomly, across servers, and can lead to developers being >>> fooled into writing code that doesn't actually work when deployed. >>> >>> Yesterday, we had an even more worrying problem, where ML seemed to >>> actually get confused about the simpleType of an element, giving us a XDMP- >>> LEXVAL for the cast of an element to an xs:dateTime, even when the format >>> was actually correct; the database seemed to think the type was another, >>> unrelated schema type. >>> >>> I've solved these problems temporarily by either clearing the Schemas >>> database and re-loading it, or by re-indexing the Schemas database, >>> although neither is a reliable fix, and re-loading the Schema's database >>> during a deployment may end up breaking it again. >>> >>> Is anyone aware of any circumstances in which this behaviour may occur? The >>> servers are not resource challenged, and the Schemas database is using the >>> out-of-the-box configuration. >>> >>> >>> Thanks >>> >>> Ellis. >>> >>> _______________________________________________ >>> General mailing list >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >>> >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
