I have a web project that stores objects in raven db. For simplicity the classes live in the web project.
I now have a batch job that is a separate application that will need to query the same database and extract information from it.
Is there a way I can tell raven to map the documents to the classes in the batch job project that have the same properties as those in the web project.
I could create a shared dll with just these classes in if that's needed. seems unnecessary hassle though
As long as the structure of the classes you are deserializing into partially matches the structure of the data, it shouldn't make a difference.
The RavenDB server doesn't care at all what classes you use in the client. You certainly could share a dll, or even share a portable dll if you are targeting a different platform. But you are correct that it is not necessary.
However, you should be aware of the Raven-Clr-Type metadata value. The RavenDB client sets this when storing the original document. It is consumed back by the client to assist with deserialization, but it is not fully enforced. The logic basically is this:
is there ClrType metadata?
if yes, do we have that type loaded in the current app domain?
if yes, then deserialize into that type
if none of the above, then deserialize dynamically and cast into the type
requested (basically, duck-typing)
You can review this bit of the internals in the source code on github here.
Related
I have written a client to a public SOAP web service, using a WSDL and several XSD files supplied by the service provider. I wanted to find an easy way to validate user data against the XSD files, so I used the standard example from MSDN, using an XmlSchemaSet for the XSD files, an XmlReader and a validation routine to catch the error messages. (The code is available at http://msdn.microsoft.com/en-us/library/as3tta56.aspx) It works for some data elements, but others do not throw an error when they are invalid. If I include "ValidationFlags = ValidationFlags Or XmlSchemaValidationFlags.ReportValidationWarnings", I then get a lot of warnings, e.g. "Could not find schema information for the element 'MyRequest'", "Could not find schema information for the attribute 'TheDate'", etc. But I can open the XSD files in the VS2010 IDE, and its XML Schema Explorer shows these elements and attributes.
So my main question to anyone who is familiar with validating XML data in VS2010 in this way is, are there limits to the complexity of the XSD files that the XmlReader validation can handle? Could the prefixes for the Target Namespaces confuse the XmlReader? There are thousands of complex types defined in the schema, spread across 7 XSD files, which is why I wanted this to be handled automatically, rather than me writing a validation routine for each user input field.
Thanks in advance.
The .NET validation may not be perfect, yet it's among the best in the industry. One issue they have for sure is with the schema loader (we use our own), which sometimes gets fooled too easily (I would say). Beside the above, I am not aware of any other limitations, along the lines you described. We routinely use .NET XmlSchemaSet to load and validate XSDs spread across hundreds of files, in all sort of namespace combinations, and with thousands of elements, types, etc.
I am using RavenDb across multiple projects and solutions to access three different databases that are all part of the same product. For instance, I have multiple MVC projects that fetch user info and some data out of the 'web' centric database and the 'backend' database, using '-' for the id override (but I need this only for a subset of classes in the 'web' db). And then I have another 'backend' database that is used by services (as well as the MVC projects). And finally a third temp/scratch database I use by another set of services to build the backend db. And of course, all of these are being accessed from different class libraries and even console test, seed, and integration test apps.
Managing all of these is becoming quite a nuisance. Every time I create a new console app or class library that access the db, I have to setup config and raven packages for each project, make sure indexes are built, etc.... Not to mention running update on all nuget updates, or in my case, installing a new unstable version of the server/client binaries.
Is there an easier way to manage this?
I tried to abstract the DocumentStore creation and initialization, as well as index creation into it own project and reference that. But the other projects then had to manually add newtonsoft.json (and nlog) from the package directory.
As well, I am getting the following when I try and abstract the DocumentStore into a class with a static property:
StackTrace of un-disposed document store recorded. Please make sure to dispose any document store in the tests in order to avoid race conditions in tests.
Anyone have any thoughts on handling these issues?
Thanks
I don't think that the manual addition of the references is a big issue, but you can add the actual nuget references as well.
Note that the DocumentStore not disposed error is something that only happened in the unstable (debug builds), and won't happen on release builds.
This is my first time that I am working on a big project for a client. So I was not sure how to solve this problem. However I have come up with two different ideas but I need professionals opinion about which one is better :)
Situation :
There is an application which runs on different client's iPad. Application data is stored by using giant XML file. This XML file is shared among all client by a server. So a server has a centralised copy and each client has their own copy. Once client made changes to their XML copy they updates server copy in and other client updates their copy by updated server copy.
Now only one client can make changes at one time, To fix this I have logic by which before client starts editing XML they need to get ownership from server and server will only allow one client to edit at one time.
Visual Representation :
Now on client side I have to think of a logic by which I will update my client copy and upload it to server. There are two options,
Option 1 :
In option 1, I can directly manipulate XML file by using GDataXML parser and upload that copy to server. For persistence I can save client copy on my iPad in document directory.
Option 2 :
In option 2, I can read XML file create a CoreData representation for local storage. When ever I update data inside core data it will I will change XML file too and than upload that file on server. Double work but I guess better persistence.
Now which one more robust and advisable? Personally I was planning to do option 2 because it seems more robust as I am persisting application data in core data. But option 1 seems more easy work but I don't know how good persistency will remain.
Sorry for lengthy question,
Thanks for any input given.
There are a number of factors which would influence selecting the second option over the first.
How big is the XML file? If you need to work with very large documents, you may need to incrementally parse the XML (SAX) into core data. This will allow you to access the document's contents without loading it all into memory at once.
Do you need to run complex queries in the data? If so, you may be better off using core data fetch predicates, rather than xpath or XSL.
Are you already using core data? Depending on how the XML data is structured, it might be simpler overall to import the data into your existing persistent store.
Otherwise, you can probably make due with parsing the entire document and either traversing the resulting tree or querying with xpath.
If you need to create an object graph based on what you get from server and show it to user (which you most probably need to do), you should stick up to second option, since it allows easy and robust data persistence.
If you do not need to present user with any data from the XML file you can, of course, store it in the Documents directory.
So, if this is a client application and it has at least some visual representation of the data from an XML file you should use CoreData.
If you want a regular update of data , then use CoreData
I've been developing several iOS applications using Core Data and it has been an excellent framework to work with. However, I've encountered an issue whereby we more or less have distributed objects (synced) across multiple platforms. A web/database server backend and mobile devices.
Although it hasn't been a problem until now, the static nature of the data model used by Core Data has me a little stuck. Basically what is being requested is a dynamic forms system whereby forms can be created on a server and propagated to the devices. I'm aware of the technique for performing this with a set number of tables with something like:
Forms table
Fields table
Instance of Forms table
Instance Values table
and just linking everything together. What I'm wondering however is if there is an alternative system to Core Data (something above talking to an SQLite database directly) that will allow for a more dynamic object graph. Even a standard ORM would be good if there are options for modifying the schema at runtime. The main reason I want to go down this route is for performance in the sense that I don't want the instance values table exploding with entries (on the local device or server).
My other option is to have the static schema (object-graph) on the iOS devices but have a conversion layer on the server's side which fetches the correct object, populates the properties and saves it to the correct table. Then when the devices comes to sync, it does the reverse and breaks it down into instances. While this saves the server from having a bloated instance value table, it could still be a problem on the device.
Any suggestions are appreciated.
Using specific tables/entities for forms and fields, and entities for instances of each, is probably what I would recommend. Trying to manipulate the ORM schema on the fly if it's going to be happening frequently doesn't seem like a good idea in general.
However, if the schema is only going to change infrequently, you can probably do it with Core Data. You can programatically create and/or manipulate the NSManagedObjectModel prior to creating a NSManagedObjectContext. You can also create migration logic so data stored in an old model can be preserved when you update the model and need to recreate the context and stores.
These other SO posts may be helpful:
Customize core data model at runtime?
Handling Core Data Model Changes
You need to think carefully about what you are actually modeling.
Are you modeling: (1) the actual "forms" i.e. UI elements, (2) data that might be presented in any number of UI versions e.g. firstName or (3) both?
A data model designed to model forms would have entities like:
Form{
name:string
fields<-->Field.form
}
Field{
width:number
height:number
xPos:number
yPos:number
label:sting
nextTab<-->Field.priorTab
priorTab<-->Field.nextTab
form<<-->Form.fields
}
You would use this to store data about form as displayed in the user interface. Then you would have a separate entities and probably a separate model to store the actual data that would populate the UI elements that are configured by the first data model.
You can use Core Data to modeling anything you just need to know what you are really modeling.
I'm working on creating a WCF Domain Service which at the moment provides access to a database. I created the Entity Model, added the DomainService (LinqToEntitiesDomainService) and everything works so far.
But there are cases when my data doesn't come from the DB but somewhere else (for instance an uploaded file). Are there any best practices out there how to handle this different data sources properly without resorting to writing two completely different data providers? It would be great to access both types with one interface. Is there already something I can use?
I'm fairly new to this so any advice apart from that is highly appreciated.
How many cases where the data comes from a file? How many files? How will you know if a file is there? Are you going to poll the directory? what format are the files? (XML support is possible)
Microsoft's documentation suggests that you can create a custom host endpoint, but I don't know what limitations there are.