How do I clear the .Schemas of a IXMLDOMDocument2 after I have added a schema to a IXMLDOMSchemaCollection2 then assigned to the .Schemas of the IXMLDOMDocument2?
So I am trying to valdiate a xml against multiple XSD one by one, but it seems the XSD gets "accumulated" at the xml document object.
Must I create a new xml document object for every validate?
There is no method to remove a schema from a schema collection so, if you want to clobber the schemata that you've previously added, you must set the IXMLDOMDocument2::schemas property to a new schema collection. If you simply want to clear the schemata without adding a new one, you can pass a VARIANT set to VT_EMPTY.
Related
I am having an issue with the partial update in SOLR. As I am having some non-stored fields in my collection the values in the non stored fields gone after the partial update. So, is that possible to use copy field to copy the original content for the non stored field from a different collection?
No. copyFields are invoked when a document is submitted for indexing, so I'm not sure how that would semantically work either. In practice what a copyField instruction does is to duplicate the field value when the document arrives to the server and copy it into fields with other names. That assumption won't make sense if there's a different collection involved - does it get invoked when documents are submitted for the other collection? (if that's the case - what with the other fields local to the actual collection).
Set the fields to stored if you want to use partial updates with fields that can't support in place updates (which have very peculiar requirements, such as being non-stored, non-indexed, single valued and has numeric docValues).
I'm running a GAE Golang application that's working with datastore. I have a struct which translates to a DB model on datastore, and I have added a new field to the struct, call it NewField (type string)
Existing instances ("rows" in the DB) for this struct have this NewField missing of course, which is expected.
I'm looking to create a query that will return all instances with where this NewField is missing (the existing instances).
This is what I tried:
q := datastore.NewQuery("MyModel")
q = q.Filter("NewField =", "")
However this doesn't seem to work.
Any ideas on how to achieve this?
The bad news is that you can't.
Every query on GAE Datastore operates on an index. Since you just added the new property, existing entities without that property will not be in any indices (that includes that property). What you would need is to loop over entities with no index records, but that is not possible.
Your best bet is to query all entities, and do the filtering / update manually in Go code, where the NewField field has the zero value. Once you re-save existing entities, the new property will get indexed, and you will be able to search / filter by that property in the future.
If by any chance your entities store the creation time or last updated time (in a property), then you may use that: filter by last updated time to list only entities where the timestamp is less than the time when you added the new property to your Go model.
Another option (for future changes) is to add a "version" property to your entities. Whenever you perform a model update, increment the version for new entities. And you can always query entities with old versions (or with a specific version).
I am currently working on a project that uses LINQ to SQL for database access. It has become necessary for me to manually update the DBML file by right-clicking on it and opening it with an XML editor because I do not want to re-generate the file and lose all of the changes that have been made to association member names.
Can someone please explain to me what the storage attribute is used for in the Association element of the DBML file? I have searched this forum and Google to no avail. The storage attribute is not present in every Association element. I have included XML in my DBML that both includes and excludes the storage attribute below:
<Association Name="Customer_WorkOrder" Member="Customer" ThisKey="CustomerId" OtherKey="Id" Type="Customer" IsForeignKey="true" />
<Association Name="Sycode_WorkOrder" Member="WorkOrderOrderStatus" Storage="_Sycode" ThisKey="OrderStatus" OtherKey="recno" Type="Sycode" IsForeignKey="true" />
http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.dataattribute.storage.aspx
Gets or sets a private storage field to hold the value from a column.
If there is no value set, it generates the private field like "_" + AssociationName, otherwise it uses the "storage" value. It is a bit confusing, since usually the "storage" term refers to the database and not to the generated code.
While creating a table that has an XML type column, I am referring to a complex XML Schema Collection. When I specify the XML Schema, I have the option of mentioning either CONTENT or DOCUMENT keyword. The latter will ensure that the XML data is stored as a document in a single column.
According to a video tutorial the CONTENT will store the XML data in fragments.
Besides the above statement I don't find reference anywhere else regarding the usage of the CONTENT keyword and it's implication on schema & data.
I would like to know how the fragments are created and managed and whether and how they can be queried individually. Further, how the fragments are correlated. Next, when I amend the XML Schema Collection, what is the impact.
actually i think SQLServer 2005 XML is quite good documented.
CONTENT is the default and allows any valid XML. DOCUMENT is more specific and means that the XML-Data you can to store is only allowed to have a single Top-Level node.
Create:
CREATE TABLE XmlCatalog (
ID INT PRIMARY KEY,
Document XML(CONTENT myCollection))
Insert:
INSERT INTO XmlCatalog VALUES (2,
'<doc id="123">
<sections>
<section num="1"><title>XML Schema</title></section>
<section num="3"><title>Benefits</title></section>
<section num="4"><title>Features</title></section>
</sections>
</doc>')
Select:
SELECT xCol.query('/doc[#id = 123]//section')
FROM XmlCatalog
WHERE xCol.exist ('/doc[#id = 123]') = 1
...and so on. The query language exceeds more or less in a subset of xpath 1.0.
If you amend an XSD it is checked on Inserts and Updates and stored within the xml of each element. As far as i understand the doc it is also allowed to add multiple schemas for one column so that entries can reference to different schemas.
EDIT:
Ok, after reading the specific parts of the documentation i think i understand what your problem is. The reference isn't very clear on that point but as far as i understand it only Entries with one top level node can to be bound to XSD schemas.
Due to the fact that XSD-Schemas require a single top level node defining the used XSD file it won't be possible to validate fragments containing more than one top level element. I haven't tried but i think it can't be done.
However it seems to be valid to define a CONTENT column, amend an XSD and store both, XML with one top level node referencing the XSD as well as XML-fragments which will only checked for wellformedness. The fragments can be accessed using the XPath query language show in the select statement above.
I can't tell you much about performance implications. The reference mentions that XSDs are stored inline so this will need some extra space within the db. The XPath queries need to be executed too. Despite the fact that xpath usually is quite fast i guess it could decrease performace cause it needs to be performed on each row to get the result. To be sure i think you have to check the execution plan for your specific query depending on size and complexity of the stored xml as well as the xpath expression.
I tried rebuilding but it seems that the edmx file doesn't update itself with the changes I made. Any suggestions besides removing the edmx and remaking it?
If you are using Entity Framework 4.0 you can just right-click the white-space in the designer, choose 'Update Model from Database' and hit Finish. This will refresh all tables.
You can add the field manually. It's not so hard, especially if it's a scalar.
Make sure your existing model is checked in in case you have to roll back!
Note the name of some other scalar column in the table, preferably one with a unique name and the same type.
Right click model, "Open With", XML Editor.
Search for the other field.
Add the new field everywhere the other field pops up. There will be at least three different places to change. But note that the field may already be in the SSDL/storage schema, which would be why it didn't add in the first place.
Look at the Errors pane to make sure you haven't messed up the XML validity.
Save and compile.
Now you can edit the new field in the GUI by re-opening the model, if need be.