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
