Question 2 - (Multi-Core)

[Herman Kiefus]

Thank you all for your guidance relative to my departure from SolrSharp to SolrNet.  I was reading through the Wiki and came upon the following statement:

 

“The built-in container (Startup) is currently limited to access multiple cores/instances with different mapped types”

 

Does this mean I will be unable to use SolrNet if I use multiple cores that possess the same document (schema)?

 

In my current scenario I have a core named ‘primary’ that receives periodic updates and serves up requests.  I also have one named ‘secondary’ that utilizes replication from ‘primary’ to remain near temporally current.  (‘secondary’ is what we point requests to if and when primary should go down.)  Lastly, we have ‘ondeck’, which is bulk loaded on a periodic basis and hot swapped with ‘primary’.

 

My point is all three use an identical schema and if I read correctly, it would seem that SolrNet does not support this scenario. 

 

If this is the case, I might also ask: “why not”?  Multi-Core appeared to me to be most useful and when I generally take a path that many others (who are typically much wiser) have not, it generally means I have made the wrong decision.  Therefore, am I misguided in my desire to use multi-core?

 

Disclaimer: Now that I think about it, ‘secondary’ in my example (which is about to roll out in our first Production release) is not actually a core, but it is implemented that way; however, we do/will rely on multi-core to have an ‘on-deck’ index that can be loaded independent of the one currently serving up requests.

[Mauricio Scheffer]

Hi Herman

Only the built-in container has that limitation. Use the Windsor or StructureMap integration if you need that feature. http://code.google.com/p/solrnet/wiki/MultiCoreAccess explains how to do it.

Why this limitation? SolrNet is an open source project driven by need. This feature you mention has been in the tracker for almost a year now: http://code.google.com/p/solrnet/issues/detail?id=83 but nobody so far cared enough to invest the time to implement it. Personally, I always use Windsor except for a few simple integration tests where I use the built-in container.

Of course, I can provide assistance if you're willing to implement it.

Cheers,

Mauricio

--
You received this message because you are subscribed to the Google Groups "SolrNet" group.
To post to this group, send email to sol...@googlegroups.com.
To unsubscribe from this group, send email to solrnet+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/solrnet?hl=en.

[Herman Kiefus]

I'd love to help, but I think my abilities might be beneath what's required.

 

I'll have to learn more about Castle Windsor; I read a bit about it and others (integration methods?) earlier today and I must admit that I'm not sure I fully understand the concepts.  I'm a bit of a minamalist by nature; just looking for some raw classes that cover all of the tedious issues when communicating with Solr.  Having said that, I can't imagine that it could be all that difficult as in my mind's eye it's not much more than adding the core name to the URL.

 

I'm sure you all will forgive my ignrance as you roll your eyes. ;)

[Mauricio Scheffer]

Sorry, SolrNet is quite dependency-injection-oriented. It may add a bit of complexity, but IMO the benefits in flexibility are worth it.

Dependency injection is not that complex... it's kind of like plug and play OOP :-) You're probably doing it without realizing it.

You can certainly use SolrNet classes without any container (all classes are public), but you'll have to instantiate a large number of classes, each with a specific responsibility, for example SolrConnection manages the HTTP connections, DefaultQuerySerializer serializes queries to Solr syntax, ResultsResponseParser parses the results from the XML response, and so on. The container assembles and manages all those classes for you.

In this particular case, the built-in container would have to provide a way to duplicate most of the object graph (= combination of assembled classes) in order to have multiple URLs per document type.

A cheap workaround would be mapping semantically equivalent document types, e.g. map a class MyDoc with all defined properties and then map a class MyDoc2: MyDoc {} to the other URL. Haven't tried it but I think it should work.

HTH.

--

Mauricio