I've not dug into the details of what and how SDL Tridion is storing data in it's internal search engine (SOLR), but I need to build a GUI extension that needs to perform searching on component/metadata fields across publications.
I can't see any reason not to have a look into SOLR, but before I invest the time, does anyone know any reason why this would be a bad idea?
Thanks in advance!
It's a bad idea in general to bypass the API and directly query SOLR.
From your question, I see no reason to do so.
Do you need to index more data than what is already indexed by Tridion?
If not, surely you can just search using the API?
If you do, you could consider implementing a custom Search Indexing Handler for the additional data. Although this is not very well documented at the moment, it seem rather straight forward to create (implement ISearchIndexingHandler and update your CM and SOLR configuration). The benefit would be that your data can also be searched for using the standard Tridion search.
It really depends on your search requirements. If it's just about simple search - then it's probably fine, but if you want to make some Tridion specific searches then it will be quite difficult as SDL Tridion does a lot of post processing on SOLR results. Why can't you just use CoreService and have a convenient supported search interface?
As Peter said, its really a bad idea to interact with SOLR that comes with Tridion. Tridion has a abstraction layer to hide complexity of SOLR query. For example tridion hides case sensivity of the search keyword.
I strongly recommend to use tridion search api to build ur interface. Tridion search api also supports executing solr query directly. But its not recommended.
For indexing additional data u can implement ISearchIndexingHandler. It has some complexity with the solr config files (adding new fields).
Related
We are upgrading to Tridion 2011 SP1 and as a part of Tridion search implementation we are using FS4SP (Fast Search for sharepoint 2010).
In proposed implemenatation search environement consists of following servers:
FAS4SP
FISE
Can someone guide us regarding how to push content to FAST from tridion and how to retrieve the same?
(Here due to some reasons we are not considering crawling of website by FAST)
What all APIs can be used for this implementation?
If you don't want to use the crawling approach, you will need to create a custom deployer, please take a look at this other article:
How can we integrate Microsoft FAST with SDL Tridion 2011 SP1?
Alternatively, if you don't have a development team who is familiar with Java, you might considering creating a .NET application which updates your FAST index based on either a File System or Database trigger when your pages or components are published, updated or deleted from your broker repository.
You will probably want to create XML for FAST and have the Custom Deployer (or Event System) send the content to FAST.
First create the FAST XML that works and write a sample app so you can insert it into the FAST index from either a .NET or Java application. This does not yet involve Tridion.
Then write your Custom Deployer or Event System and pass the XML to FAST.
IF you are using a Custom Deployer approach I would suggest to contact Tridion Professional Services if you have not done it yourself or are not a Java programmer. The new Tridion 2011 Storage API provides new opportunities for the Custom Deployer. In the meantime I would suggest to append the FAST XML to the normal Page Content at the end, surrounded by some markers, and have your custom deployer pull it out of the Page output, send to FAST, then remove from the output before continuing.
This is a fairly difficult challenge for those who do not have serious Content Delivery / Deployer / Java skills. However, if you want to go for it yourself I would suggest taking at least 2 weeks of time to research existing solutions and experiment with the API.
Using the Event System might be a little easier - but your success or failure message will not appear in the Publish Queue and if the search index fails to update you can only log the failure and not pass the info back to users.
SDL Tridion's TOM.NET API replaced the deprecated TOM (Tridion Object Model) starting in, I believe, version R5.3.
Aside from asking Stack Overflow (Exchange) questions, which documentation should we refer to when working with and learning the TOM.NET API?
So far, I've found (logins required):
SDL Live Content
TridionWorld Download (select latest version, currently 2011 SP1 to download the "SDL Tridion 2011 SP1 TOM.NET API" chm)
I see these (plus questions on the forum), but can't tell which is better. What do you use most when working with TOM.NET?
Good Question and Probably most of the Tridion new developers might be wondering the same when to to use which. I would say both the documents has a different purpose and go side-by-side. API Documentation does provide information on methods and usage, SDL Live Content docs provide information is more of understanding what to use for your scenario. We do get these kind of questions when we are on boarding any new developer "Which document provides me the most information".
I refer to these simple examples to explain the differences on when to use which documentation.
what variables are available in package (vs) What API method to use when reading variables from package ?
Referring Live Docs for the first and API doc for second
How do I loop through the embedded fields (vs) what method I use to loop through embedded value fields ?
Referring Live Docs for the first and API doc for second.
I see this question with different variation keep popping up almost every month.
I know I used simple use cases, but sometimes keeping it simple is better.
Hope this information helps.
Also according to this page in the documentation the TOM.NET API should be only used in Templating and Event Handlers. For third party applications you should use the Core Service API.
I use the API documentation, and when I really want to know more use Reflector. But that's not really advisable(?).
Is there any good search tools for asp.net I can buy to carry out search indexes easily on data I have in my database?
What I require is something that would carry out a general site search of articles but also faceted search as well. Faceted search is quite important feature.
Thanks.
You can implement facets with Lucene.NET, Solr, Sphinx, FAST, Endeca, probably also Xapian.
None of these will be trivial to integrate though, since they use very different data structures from relational databases. Usually you have to denormalize your data to feed it to a full-text search engine.
SolrNet includes a sample ASP.NET MVC application that shows how to implement facets with Solr.
Disclaimer: I'm the author of SolrNet.
I agree with Mauricio Scheffer, using Solr.NET will help achieve what you want. I implemented a basic ASP.NET web form example around a year back. I found this link to be very useful to get me started: http://crazorsharp.blogspot.co.uk/2010/01/full-text-search-using-solr-lucene-and.html
Using the example (above), I managed to create this (DISCLAIMER: personal site): http://surinder.computing-studio.com/post/2011/01/14/At-Last!-Created-My-Own-eBay-Style-Search-Using-Solrnet.aspx
Lucene .net great http://incubator.apache.org/lucene.net/
Its a .net port of the very popular Java search library Lucene.
Now, I prefer having a stand along search engine to remove the strain from my site. I use Solr which is Java, but you can use SolrSharp http://solrsharp.codeplex.com/ or SolrNet http://code.google.com/p/solrnet/ to intergrate with solr.
I have no experience building a search solution, but I'd like to have a search box within my solution and I don't know where to even begin. Are there cool SQL Server tricks that I can use to make my search solution performant (I'm using a hosted SQL 2008 server) I'd love pointers to a multi-step tutorial that starts me off with a simple query search solution...and then layers on more advanced code and features.
You don't actually say whether you need/want a 'spider' to index your site "as is" (like Google; which is useful if your searchable content on each page comes from many different tables/objects/entities) or whether you just want to query EF using full-text-search-like syntax to return a collection of Entities?
If you are interesting in the 'spider' approach - here's a CodeProject article for a small ASP.NET Search Engine "Searcharoo". It is a web-crawling search engine for small-ish sites (it doesn't use a database at all), so it may not be applicable for your situation.
The code is also at searcharoo.codeplex.com and there are 7 articles on how it works/was built at Searcharoo.net (disclaimer: I wrote them; I hope they are interesting/useful).
If you need to search your database directly, you should probably look into SQL Server 2008's Full Text Search feature (assuming LIKE isn't sophisticated enough for your needs). We used info from this article (free registration) to set-up SQL Full Text Search on a work project... no EF in our solution though.
Also, as you might know StackOverflow is built with ASP.NET MVC - they blogged about some problems with SQL 2008 FTS. There's also some info on SQL FTS versus Lucene.NET (which is another search engine you could research) that might be useful.
You might be interested in reading this.
Read this article:
Create a Site Search Engine in ASP.NET
If you don't have to program an engine yourself you could consider using Google Custom Search Engine. There are couple of articles about this:
Using Google Co-op's Custom Search
Engine
Implementing Search in ASP.NET with Google Custom Search
Also could be useful:
Helping Visitors Search Your Site By Creating an OpenSearch Provider
What's your preferred method of providing a search facility on a website? Currently I prefer to use Lucene.net over Indexing Service / SQL Server full-text search (as there's nothing to set up server-side), but what other ways are being used out there?
We used both Lucene.net, Indexing Service and SQL Server full-text. For a project with large and heavy DB search functionality SQL search has an upper hand in terms of performance/resource hit. Otherwise Lucene is much better in all aspects.
Take a look at Solr. It uses Lucene for text indexing, but it is a full blown http server so you can post documents over http and do search using urls. The best part is that it gives you faceted searching out of the box which will require a lot of work if you do it yourself.
you could use google, it's not going to be the fastest indexer but it does provide great results when you have no budget.
dtSearch is one we've often used, but I'm not really that big a fan of it.
A lot of people are using Google's custom search these days; even a couple of banks that I know of use it for their intranet.
If you need to index all the pages of your site (not just the ones Google indexes) or if you want to create a search for your intranet web sites, the Google Mini is pretty sweet. It will cost you some money, but it is really easy to have it up and running within just a couple of hours. Depending on how many pages you need to index it can be expensive though.
I'm using dtSearch and I (kind of) like it. The API isn't the greatest in the world for .NET but it can get the job done and it's pretty fast. And it's cheap, so your boss will like it (~$1,000 US).
The results leave something to be desired as it doesn't do any kind of semantic relevance rankings or anything fancy. It does a better job than anything you can get out of MS SQL server though.
It has a web spider that makes it easy to do quick search apps on a website. If you need to you can use the API to create hooks into your database and to provide item level security - but you have to do the work yourself. Their forum leaves something to be desired as well but maybe people will start posting dtSearch stuff here. :)
Has anyone tried Microsoft search server express?
http://www.microsoft.com/enterprisesearch/serverproducts/searchserverexpress/default.aspx
I haven't tried it yet, but it could potentially be powerful.
From the site it looks primarily geared towards sharepoint users but given its sdk I don't see why you couldn't use it for a regular old site search
I also recommend SOLR. It's easy to set up, maintain, and configure. I've found it to be stable and easy to scale. There's a c# package for interfacing with solr.