I am RavenDB noob trying trying to understand how does RavenDB knows to link a document to another?
It appears to me that it scans every property of the document and if the proprety value matches a documentId, it shows that a reference in the studio, even though I didn't really try to make it a reference.
Is there a way to avoid this behavior?
Thanks,
Juma,
This is merely a UI feature, it is based on looking for conventions, and it has no operational impact.
Related
I rewrote a news application (overview + detail) from Fast-Query to Content Search. The performance gains were enormous, but i see some possible limitations, for which i don't know to handle in conjunction with the Page Editor.
When i use a fast query, i get an instance of a news even if there isn't a language version yet. In Lucene, i cannot find a result (because i filter for the language) and therefore the news detail is missing in the overview in the particular language.
EDIT for question 1
Lets assume that we have a solution with two languages (English and German). I have an item which currently only exist in a single english version. When i'm on an overview page in German and want to find this item with an fast query (the query does not matter), i will get this item back. In the wrong version, but i get it back. Now if i'm in Page Editor, i can go to this item and edit this in German, even if there is no version yet. The first click on the save button will create the first version for me.
When i want to find the item trough the Content Search, my natural way of query it is by making the same filter (probably by template, path and some channeling or whatever) AND a filter by the language property of the SearchResultItem, since i don't want multiple results for the same item. But since there is only a english version yet, the index only contains a single result in english and because of the language filter, i cannot find this item to call GetItem on it.
Since writing this question initially, i see two approaches to get around this:
a) Remove the language filter in Page Editor mode and filter it afterwards somehow (I don't know whether i'm able to get an item which i can edit in Page Editor in the German language)
b) Create a Page Editor specific master search index which holds an entry for all languages in the solution for every item, even if there isn't any in the specific language. I can add a computed field to indicate, whether this result is a real item version or not to filter at some point if necessary. Probably i'm able go call GetItem on this and enable Page Editor capabilities.
With lucene, i cannot find the detail item in a (currently) non-existing language version when i want to resolve it by it's display name trough Lucene (because there is no language version indexed yet).
EDIT for question 2
This goes hand in hand with question 1
In relation with Workflows, i see possible struggles with the Version which is indexed. Is the first Version in index, before you approve the version? Otherwise the overview has no chance to show this item till it is approved in Content Editor.
Has anybody used the Content Search for Page Editor relevant actions and has some advice how to get around such problems?
I've had the same issues with Sitecore 7, and while I don't have the ultimate solution for you, hopefully you will find the following information helpful.
I can't word my answer any better than this post: http://thegrumpycoder.com/post/75524076869/sitecore-content-search-beware-of-the-context
With Sitecore ContentSearch you are choosing which search index you would like to use. You are likely using sitecore_master_index when in Page Editor / Preview mode, and sitecore_web_index on the published site. As the web database only has one version of each item, you don't need to worry about their being multiple versions in the index. However sitecore_master_index will by default index all versions of an item in all languages. You can then potentially see items showing up multiple times in your listings components if you're not careful.
Sitecore 7 has a field "_latestversion" which you can add to all your queries, but it isn't reliable for a couple of reasons:
The latest version isn't necessarily the correct one, taking into account things like publishing restrictions and what date you have selected in the "Experience" view.
Due to a bug I have often been able to cause there to be more than one version of an item in the index where _latestversion is 1. Not after a complete rebuild, but after an edit or two. I saw this in Sitecore 7.0 and I'm not sure if it's been fixed yet.
Read http://www.sitecore.net/Learn/Blogs/Technical-Blogs/Sitecore-7-Development-Team/Posts/2013/04/Sitecore-7-Inbound-and-Outbound-Filter-Pipelines.aspx for more information on how you can use "Inbound filters" to ensure only the latest version makes it into the master index, but bear in mind that doesn't really solve the core issue in my opinion as the latest version isn't necessarily the correct one.
So taking this, and the fact that you need language fallbacks, you should probably not filter these results out at the Lucene level, but do the necessary magic yourself in code. This would need to:
Group versions together by their items
Choose the right version based on the current language, date, security and workflow
Apply your desired fallback logic if said version isn't found
Somehow work in pagination into this in a way which performs well
I also feel the following SO question is relevant:
Indexing Sitecore Item security and restricting returned search results - something else which can catch you out when you expect the Search API to work exactly in the same way as the Query API.
I'd be interested to know your thoughts and if you ever find a better solution! Thanks, Steve.
I am struggling with the AtTask API. Specifically, I'm finding the documentation to be confusing and the examples to be very limited. For instance, the API supports "Named Queries" but there seems to be no listing or documentation of them. One point says that they are listed under "Actions" in the API Explorer, but I find very little there, and the named query that is used in the example "myWork" is not listed.
Can anyone point me to better documentation or examples? I can muddle through by trial and error, writing all my own queries, but it would be nice to know if there is already a Named Query that does what I need to do. For Instance, I need to get a list of assigned tasks. myWork returns a list of tasks that have already started, but I also need the work requests.
Any help will be greatly appreciated.
Thanks,
Mark
There is no question that the AtTask documentation is very weak and that undocumented features exist. Very frustrating. One thing that does help sometimes is to call the meta data for an object.
To view a tasks meta data go to cl02.attask-ondemand.com/attask/api/v4.0/task/metadata
Then just copy and paste the result on this page http://json.parser.online.fr/
It's not the best, but I found a few undocumented features that way.
Regarding getting a list of assigned tasks, I would consider just querying the tasks object with a user ID set as the search critera. Something like
cl02.attask-ondemand.com/attask/api/v4.0/task/search?method=get&assignedToID=5419c3e90001c026e1b72b7014e8e694
Can I force a ravendb collection to stay in memory so that the queries are fast. I read about aggressive caching but the documentation only talks about the request caching. If I have sharding enabled can I force all the shards to cache the collection in memory ?
Any help is appreciated,
Thanks
RavenDB doesn't really have "Collections" in the sense you are thinking. The only thing that collections are used for is to filter documents by their Raven-Entity-Name metadata. This serves a few purposes:
The Raven Studio UI can group things to make them easier to find.
Indexes can use a shortcut form of docs.EntityName instead of having a where clause against the metadata in every index.
But that's pretty much it. They aren't isolated on disk. For example, when Raven indexes documents, every index considers all documents. Docs get discarded quickly if they don't pass the collection filter, but they are still put through the pipeline.
You can read more about collections here.
Also - As long as you are still in a learning phase, you may want to post these style of questions on the RavenDB Google Group instead. You will get a much better response. You won't get much rating on StackOverflow when you are asking non-code "can X do Y?" questions. Come back here when you have written some code. See the ravendb tag for other questions that have been answered, and you'll get a feel for what StackOverflow is for. Thanks.
You don't need to do that.
RavenDB will automatically detect usage patterns and keep frequently requested documents in memory.
My project is in ASP.NET MVC3, SQL Server 2008 and using Fluent NHibernate.
I now have a requirement to audit certain properties of a specific object.
i.e. recording the old and new value of the properties changed on that object and also create and delete events on the object itself.
I think there can be several ways to approach this task - database triggers, INotifyPropertyChanged interface, or any NHibernate provided features?
Alternatively any open source libraries that will make my life simpler.
However, what i am not sure about is which path to choose. I mean this is a very vast area where I can go on exploring and still can't come to any conclusion.
It will be really helpful if I can get some guidance as to which option will be best considering my requirement and I can look into it more from there.
Thanks a lot.
Maybe I'm a bit biased but...
Have you had a look at Envers? https://bitbucket.org/RogerKratz/nhibernate.envers
I am building a faceted search with Lucene.NET, not using Solr. I want to get a list of navigation items within the current query. I just want to make sure I'm pointed in the right direction. I've got an idea in mind that will work, but I'm not sure if it's the right way to do this.
My plan at the moment is to create hiarchry of all available filters, then walk through the list using the technique described here to get a count for each, excluding filters which produce zero results. Does that sound alright, or am I missing something?
yeah. you're missing solr. the math they used behind doing faceted searching is very impressive, there is almost no good reason to not use it. the only exception i can find is if your index is small enough you can roll your own theory behind it, otherwise, its a good idea to stand on their shoulders.
Ok, so I finished my implementation. I did a lot of digging in the Lucene and Solr source code in the process and I'd recommend not using the implementation described in the linked question for several reasons. Not the least of which is that it relies on a depreciated method. It is needlessly clever; just writing your own collector will get you faster code that uses less RAM.