Hi Mary, I would like to extend this thread just a bit more...I have concerns about the background checking against schemas. I understand the technical reasons for type checking but there seems to be some wrinkles in the practical outcome.
But to make sure that I understand the jist of your responses to this thread: if the Schemas db has a schema document with the same namespace as the xml documents in a db that points to said Schemas db, then operations on the xml documents that require type checking (e.g. fn:data, and many others) will cause MarkLogic to do an IMPLICIT verification/check against the schema document. So, if for some reason (see below) I do not want this background checking done when operating on the xml documents, is my only choice then NOT to have any schema documents (with same namespace as xml doc) in the Schemas db? Sounds fair BUT what if I still want to be able to do EXPLICIT validation against the schema??? [BTW, this is how I understood things to be with MarkLogic, especially since it claims to be quite functional in a Schema-agnostic world.] In summary, my understanding was that schema validation was totally under my control via an EXPLICIT call to validate. So, what is my reason for not wanting the implicit validation? Well, during a high stress period in my organization, when we reload all our databases, I found myself staring at documents being ingested in MarkLogic (4.1-7.1) that were mysteriously having an attribute being added to them upon ingestion, even though I made sure that nowhere in the loading this was explicitly happening. After cracking my head for a while, I had the realization to look at the schema in the Schemas database being pointed to in the db config, and saw that the attribute being added was an *optional* attribute in the schema with a Fixed value (i.e. this attribute may not occur but when it does, it always has the same value). My next step was to remove the schema document from the schema database in order to eliminate the remote possibility that MarkLogic was doing some background schema validation (WHICH NOW I KNOW IT DOES). To my surprise (and dismay) at the time, the problem was solved by removing the schema document...no longer the attribute was being incorrectly added to the elements in the xml documents. And by golly, no longer was I going to put any schema documents in the Schemas database and go through some similar bad experience. NOTE: similar unwanted interactions between schema and xml documents have been experienced by other developers in my organization (ML 4.2-9) (with current tickets opened yet still unresolved). So, what can be done here? Should MarkLogic perhaps offer a switch in its db config page that allows us to NOT want background schema validation and avoid its bad side effects? Or? Please advise. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mary Holstege Sent: Tuesday, October 23, 2012 1:22 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Creating a new schemas database On Tue, 23 Oct 2012 10:17:11 -0700, David Lee <[email protected]> wrote: > One more question unanswered ( please correct me if I am wrong). > > On data Ingest ... if range indexes are created and the document has a > schema then the schema is used to help type coercion of the values. > I found this in particular for list values where "1 2 3" could only make > sense as a list of integers with a schema, so that implies that schema > is read on (some?) cases of range index population. > Since you wouldnt know without looking in the schema, I am presuming the > schema DB is searched for ALL ingested data documents (well most likely > the cached schema document table) > Yes. Schemas are also used to determine whether a range index is a list type. //Mary _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
