If you are using an index you need to set the sortoptions for the Order property. From http://ravendb.net/docs/client-api/querying/static-indexes/customizing-results-order Numerical values, on the other hand, are stored as text and therefore require the user to specify explicitly what is the number type used so a correct sorting mechanism is enforced. This is quite easily done, by declaring the required sorting setup in SortOptions in the index definition: Sort(x => x.Order, SortOptions.Int); The index outlined above will allow sorting by value on the user's age (1, 2, 3, 11, etc). If we wouldn't specify this option, it would have been sorted lexically (1, 11, 2, 3, etc). The default SortOptions value is String. Appropriate values available for all numeric types (Byte, Doub

I figured it out: I have to wait for non staled results. So if I change my Query out with this: session.Query<Model.Category>().Customize(cr => cr.WaitForNonStaleResults()).ToList(); it works just fine.

If you try to instanciate var ctrl = new Activation(); and do ctrl.validate(x); it won't work as OnActionExecuting didn't run. That function is called automatically by the MVC framework when serving a request, not when manually testing. Since MVC instantiates a new controller on each requests anyway, you should move the RavenSession initialization to the constructor since you do not seem to use any info in the request context: public class RavenBaseController : Controller { public IDocumentSession RavenSession { get; protected set; } public RavenBaseController() { RavenSession = MvcApplication.Store.OpenSession("ravendbtesting"); } protected override void OnActionExecuted(ActionExecutedContext filterContext) { if (filterContext.IsChildAction) retu

Yes. You can now do this. Enable the Scripted Index Results bundle Write your first index, for example - a map/reduce index. Write a script that writes the result back to another document. Write a new index against those documents. As changes to the original documents are indexed, the resulting changes get written to new documents, which then get indexed. Repeat if desired, just be careful not to create an endless loop. This is a new feature for RavenDB 2.5. Oren describes it in this video at 21:36.

What are you trying to do? If the end result is to query all Principals, then load the entire User or AppInstance, why not just go straight for querying all Users or all AppInstances? Raven won't store base classes; it will only store the most derived type (User or AppInstance, in your case). So you'll have a collection of Users and a collection of AppInstances. If you really need to query both at once, you can use Multi Map indexes. You can also change the entity name and store both in a single Principal collection. But it's difficult to recommend a solution without knowing what you're trying to do. Explain what you're trying to do and we'll tell you the proper way to get there.

You have 2 options: Use RavenHQ and assign the connection string, see http://support.nservicebus.com/customer/portal/articles/859362-using-ravendb-in-nservicebus-%E2%80%93-connecting Use SqlServer as persistence

result.OrderBy(x => x.Field.Name) will return a collection as LINQ will not change the collection on which it is called rather it returns a new collection which has the required result. So do result = result.OrderBy(x => x.Field.Name);

You should probably not be upserting one record at a time. RavenDB has a bulk insert feature that will make things much easier and faster. See http://ravendb.net/docs/2.0/client-api/advanced/bulk-inserts

Connecting locally, are you using http://localhost:[port]? I've had problems using the domain name locally. Try running your application locally and connect to the RavenDB via locahost address.

The Array intersection is not allowed, but you can write your query as follows: var colors = session.Query<Color>() .Where(c => c.colorArray.Any(x => x == "r") && c.colorArray.Any(x => x == "e") && c.colorArray.Any(x => x == "d")); Please note that in order for this to work, you need to use strings, not chars. The colorArray property in your Color class needs to be defined as: public string[] colorArray { get; set; } The reason is that if you use char[], then the query will check for the numeric values (ASCII codes) rather then the string values (ex: 'r' will be interpreted by the query engine as 114, 'e' to 101 and 'd' to 100). Now, to take this

From what I understand, Load will guarantee to return a result (provided that id exists in the database) whereas Query might not return a result if the indexes haven't yet been updated. You could have a scenario whereby you insert a record, then on the next line try to retrieve that same record using Query and then not get anything back. Load would return a record in this scenario. So I guess the performance degradation you are seeing might be related to the fact that you are querying by index when using Query, whereas Load is hitting the actual data store.

The Id property of the Product class must be of type string instead of integer. Then you will be able to retrieve the autogenerated id after the operation: Product p = new Product() { Title = "My Fancy Product" }; RavenSession.Store(p); string id = p.Id; More information can be found in the documentation (Document IDs section): In the example above we had a string Id property for BlogPost, and left it blank. It is this property that will be used as the "primary key" for this document. Note how RavenDB generated an ID for us, "BlogPosts/1", based on the default convention which we will discuss in a second. If there is no Id property on a document, RavenDB will still generate a unique ID, but it will be retrievable only by calling session.Advanced.GetDocumentId(objec

The behavior your seeing is valid, and is not because you couldn't catch the exception. It's because the exception was already caught for you. In RavenDB, if you try to load a document that doesn't exist, the Load or LoadAsync methods will return null. They will not throw an exception. When you are debugging, you are seeing that under the hood a WebException is thrown when the HTTP response comes back as 404. That exception is handled. You should see it in the output window as a "First Chance Exception". This is all normal behavior. If you want to check that you can catch exceptions, try something that will actually throw an exception. Perhaps load a document of one type while trying to cast it into another. That will certainly throw an exception.

By default, queries return up to 128 records. Use an explicit Take(n) to get more records.

You don't need RavenDB for that. Just use System.IO.File and related concepts. Raven won't work with individual files on disk. It keeps it's own set of files for its index and data stores. Access from other programs is not allowed. What happens in RavenDB, stays in RavenDB. Most people store big files on disk, and then just store a file path or url reference to them in their RavenDB database. Raven also supports the concept of attachments, where the file is uploaded into Raven's database - but then it wouldn't be available as a single file on disk the way you are thinking.

Assuming that Controller.Post(testString) is adding a new entry, you probably just have a stale index. In the real world, some natural amount of time would pass between post and query. In unit tests, you don't have that delay, so it's common to provide the following on your index: .Customize(x => x.WaitForNonStaleResults()) This is not something you should do in production. You can read more in the documentation here.

There's two main parts to consider here. Firstly, as you have already noted, if you go by the word of the more fanatical RavenDB fans it is some mythical beast which is exempt from the otherwise commonly accepted laws of good application design and should be allowed to permeate throughout your application at will. It depends on the situation of course but to put it simply, if you would structure your application a certain way with something like SQL Server, do the same with RavenDB. If you would have a DAL layer, ORM, repository pattern or whatever with a SQL Server back-end, do the same with RavenDB. If you don't mind leaky abstractions, or the project is small enough to not warrant abstracting your data access at all, code accordingly. The main difference with RavenDB is that you're g

You will have to reference RavenDB from the class library, you can't really go around that. You may find the following article insightful, though: http://novuscraft.com/blog/ravendb-and-the-repository-pattern

Since you said in comments: ... a Book from a year ago should show the custom fields as of a year ago. There are only two viable options I can see. Option 1 Custom field definitions exist in their own documents. Every book contains a copy of the custom field definitions that apply to that book, along with the selected values for each custom field. They are copied when the book is first created, but could be copied again as your logic sees fit. Perhaps on edit, you might want to take a new copy, potentially invalidating the current selections. Advantages: Self-contained, easy to index and manipulate. Disadvantages: Lots of copies of the custom field definitions. Storage requirements could be very large. Option 2 Use the Temporal Versioning Bundle (disclaimer: I am its author

Well, I'm not sure what mechanism you are using for event processing, but I have been in a similar situation with something like NServiceBus. I don't think this exactly a RavenDB problem. You would probably have the same issue if you were writing to a SQL Server database. The generalized problem is, Create and Update events are fired off, but they are received and processed in the wrong order. What to do? Well the general advice is that your event handlers should be idempotent, and should retry when failed. So if Update is received first, it will throw an exception and be scheduled for retry. Then Create comes through, then Update retries and all is good. Specifically blocking and waiting in the handler for the Update event is not advised, because if you had several of these then t

First, we'll tackle the index, note that child keys are prefixed with Children_ (required by Raven): public class Objekt_ByCodeAndChildren : AbstractIndexCreationTask<Objekt> { public Objekt_ByCodeAndChildren() { Map = objekts => from objekt in objekts from child in objekt.Children select new { objekt.Code, Children_Role = child.Role, Children_Place = child.Place }; } } The query itself: session.Query<Objekt, Objekt_ByCodeAndChildren>() .Where(o => o.Code == "1" && o.Children.Any(c => c.Role == "A" && c.Place =

If your Raven client does not have the interface already you will need to craft it yourself. You will need to make a factory instance implementing all of the members on that interface and pass it across.

I believe you can use database commands (Query) to accomplish what you are trying, as long as you know the name of the document collection you are trying to get. See here for more information. QueryResult sites = store.DatabaseCommands.Query( "Sites/ByTitle", new IndexQuery { Query = "Title:CN*" }, null);

There are multiple ways to do this, but the easiest way would be to provide your own document key instead of using the one Raven generates. This is often referred to as using "structured" or "semantic" keys. Here is a good description of the general technique. Simply add a string Id property to your class. You want the document key to reflect the unique key you described, so probably it should have a value such as "reports/2013/Q1/bob" (but you might want a more unique value for user). You can let .Net construct the key for you in the property getter, such as: public class Report { public string Id { get { return string.Format("reports/{0}/Q{1}/{2}", Year, Quarter, User); } } public string User { get; set; } public int Quarter { get; set; } public int

You should check that the index "Raven/DocumentsByEntityName" is defined for the target database, and that your document has the correct metadata information. The metadata should have a line like this: "Raven-Entity-Name": "CountryRegion" If this does not help, please also post the ravendb version you are using. A fiddler trace might also be helpful.

This appears to be a bug in the query provider for DocumentSession.Query<> where it will not honor the Newtonsoft attributes on documents. However if you use the Lucene query provider it will perform as expected: [Test] public void Test() { using (var session = DocumentStore.OpenSession()) { session.Store(new Parent {Inner = new Child {Num = 1}}); session.SaveChanges(); } using (var session = DocumentStore.OpenSession()) { var list = session.Advanced.LuceneQuery<Parent>() .WhereEquals(x => x.Inner.Num, 1) .ToList(); Assert.That(list.Count, Is.EqualTo(1)); } }

The best idea here would to not have them as separate documents. A single document can contain all of this. In other words, the structure you've described as the view model can be stored directly into the database as your document structure. Of course, that means that you will always be retrieving the document by the top-level id. Without additional context of what these nodes represent, it's hard to say if that is appropriate or not. Also, it looks like you are getting good feedback from this thread on the RavenDB Google Group already. Try not to cross-post in the future. If you want something very specific, then StackOverflow is great. If you need more of a general how-to or debate of ideas, then use the Google Group. If you can edit your question to be more specific, perhaps sh

RavenDB uses Lucene for it's searching, which is optimized for search terms, not substrings. It uses analyzers to define what terms exist within a string. Using any of the built-in analyzers, when you take a string like "hello world", the terms are "hello" and "world". Only two index entries are created. If you search with a wildcard at the end, such as he*, it can still scan the index sequentially and match the terms. But when you place a wildcard at the beginning, such as *old, then it has to scan the entire index in order to respond. In the vast majority of use cases, full substring searching is overkill. But if you want to enable it without killing performance, the trick is to use an analyzer that creates terms from the substrings. This is implemented in the NGram Analyzer.

If the only difference between products is the translations, I would go with a different model. The product document would have categoryId, price and all the rest of the product info. Assuming a product is saved under products/1, you can then save additional documents under IDs like products/1/en, products/1/es etc and store the translated strings there. You can then use ResultTransformers to inject the translated strings into the end result of queries.

While metadata is returned in the @metadata section, that's not how you send it in. That's because you don't have control over every metadata value. For example, passing in an etag wouldn't make sense. Instead, for the metadata values you can control, send them in the HTTP headers. $headers = @{"Raven-Entity-Name"="Entries"} Invoke-RestMethod -Headers $headers ...

Take a look at the TraceRecord (line 4); it contains the specific serializer exception: <Message>Could not create an instance of type ABC.Model.Users.IUser. Type is an interface or abstract class and cannot be instantated. Path 'RoomNumber'.</Message><StackTrace>

Putting aside the rename and what might have worked before, the error matches the query you are attempting. You are indexing documents of type RewardProviderLog, and retrieving them directly as type ImportMonitorViewModel. You say all of the properties are the same in both classes, but that alone won't get RavenDB to duck-type them for you. You have to be a little more explicit. This will probably work: model = (from log in session.Query<RewardProviderLog>("ImportMonitorLogs") orderby log.lastRun descending select log).As<ViewModels.ImportMonitorViewModel>().ToList(); Or if you want slightly cleaner syntax (IMHO), this is equivalent: model = session.Query<RewardProviderLog>("ImportMonitorLogs") .OrderByDescending(x=> x.lastRun)