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
