Suppose that you are developing and implementing such a solution. You'd have setup a bunch of collections and setup their crawlers such that the appropriate documents are included under each collection. During the course of this solution's implementation you'll have a need to discard all the documents in a particular collection and crawl everything from scratch. A typical scenario is when you fix a bug in indexing and want to apply the fix to the documents already in the index as well.

The tool to do this is the 'collection-admin.cmd' command-line utility present in the <ESP_HOME>\bin directory. The exact command to use is this

collection-admin -m clearcollection -n <collection>

In the above command, the -m flag indicates the mode to run the tool in. In our case we use to the 'clearcollection' to indicate we want to delete/clear or reset the collection.  '<collection>' is the name of the collection you want to reset. You can find the name in the admin GUI or using the following command with the same tool

collection-admin -m listcollections

When you invoke the command, the UI will look like this

When this command returns, all documents in the collection would have been deleted. You can then do a full crawl to repopulate this collection with appropriate documents

More information and command line options to run the 'collection-admin' tool can be found in the tool's own commandline help.

In my previous blog post I had mentioned that we were in the process of setting up regular automatic source pushes to the codeplex DLR project. I am happy to announce that work is now complete and our DLR sources are now available here. Going forward, the sources from our internal main source control branch will be available on a regular basis at codeplex.

We haven't yet decided on the update frequency and should finalize this in a day or two. Currently, we are considering either weekly or daily source pushes.

Going forward, we will update this project regularly with binaries, weekly source drops and related documents.

Please try this release and let us know your feedback. You can contact me directly through comments or email or send an email to dlr@microsoft.com with any questions related to the DLR.

P.S : The codeplex.com site also lets you subscribe and follow the discussions on this project.

The API to create a runtime and a python engine without using a config file is

ScriptRuntime runtime = IronPython.Hosting.Python.CreateRuntime();

A reference to the IronPython assemblies – IronPython.dll and IronPython.Modules.dll are needed for this call to work. The previous sample already has the proper references in place and this call would automatically work in that project.

The attached self contained sample(for VS 2008) addresses this and tries to make it easier to ‘get started’. The sample is a very simple console application that -

1)      Hosts the dlr

2)      Uses the ScriptRuntimeSetup.ReadConfiguration() and the ScriptRuntime constructor to create the runtime based on the entries in the App.Config file

3)      Creates 2 language engines – one for IronPython and 1 for IronRuby

4)      Creates a variable in IronPython and prints the value in C#.

The sample contains a pre configured App.Config file. You should be able to just extract the files locally and build the sample and execute it.  The dlr and language binaries are also included (in the ‘lib’ folder). Note that these post IronPython V2 beta4 binaries are for demo purposes only and come with no warranty or support.

HelloDLRWorld.zip

The biggest change this spec introduces to the beta4 binaries is the way the hosting runtime is initialized.

Prior to this update, the hosting runtime is initialized by creating a new ScriptRuntime object. Now, a typical runtime initialization involves 2 things.

A quick 5 min how-to on the new initialization is as follows

1)      Setting up entries in the application’s config file. Here is a sample config file

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <configSections>

    <section name="microsoft.scripting" 

             type="Microsoft.Scripting.Hosting.Configuration.Section, Microsoft.Scripting, Version=1.0.0.5000, Culture=neutral, publicKeyToken=31bf3856ad364e35"     

             requirePermission="false" />

  </configSections>

  <microsoft.scripting>

    <languages>

      <language names="IronPython,Python,py"

                extensions=".py"

                displayName="IronPython 2.0 Beta"

                type="IronPython.Runtime.PythonContext,IronPython, Version=2.0.0.5000, Culture=neutral, publicKeyToken=31bf3856ad364e35" />

      <language names="IronRuby;Ruby,rb"

                extensions=".rb"

                displayName="IronRuby 1.0 Alpha"

                type="IronRuby.Runtime.RubyContext, IronRuby, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

    </languages>

  </microsoft.scripting>

</configuration>

2)      Calling the following methods

ScriptRuntimeSetup srs = ScriptRuntimeSetup.ReadConfiguration();

ScriptRuntime runtime = new ScriptRuntime(srs);

The easiest way to implement the IAttributeCollection interface is to implement the CustomSymbolDictionary defined in the the Hosting API. Once this is done, all variable access by a script executing in the context of this scope will result in a call to the set or get methods that were overriden.

You can do some interesting things like chaining of scopes, inspecting variable values upon script access, value validation etc using this symbol dictionary implementation.

The following example uses a custom symbol dictionary to chain scopes to create a pseudo hierarchy.

ScriptScope is one of the key types available in the DLR Hosting API. They act as a context in which hosts execute code and record the effects of execution like changes in object values, creation of new objects etc.

Prior to any code execution, ScriptScopes can be populated with variables by hosts using methods defined in this type and these variables are then available to any code that’s executed in its context. ScriptScope also acts as a unit of isolation - it maintains state, isolates side effects from code and can be reused as a context to execute another code snippet.

The Hosting API spec describes this type in detail. The following list is a short summary of some of the key points described by the spec

• This class represents a namespace essentially. Hosts can bind variable names in ScriptScopes, fetch variable values, etc. Hosts can execute code within scopes for distinct name bindings.
• You create instances of ScriptScopes using the CreateScope and ExecuteFile methods on ScriptRuntime or CreateScope on ScriptEngine. 

o    ScriptScope scope = pythonEngine.CreateScope();

o    ScriptScope scope = runtime.CreateScope();

o    ScriptScope scope = runtime.ExecuteFile(@"C:\Foo.py");

• If a ScriptScope were created with a default language, then members such as Execute and IncludeFile use that language's engine to perform these operations.  If the ScriptScope has no default language, then these convenience methods throw an exception, and the Engine property returns null.
• At runtime, the DLR manifests a ScriptScope object as a dynamic object. This means that normal object member access sees the variables stored in the scope, not the members of the static .NET ScriptScope type.
• Hosts can use ScriptScopes to execute any kind of code within their namespace context. This method offers an easy and convenient way to execute a piece of script code and get a result from the execution. The variables from the execution are also bound to this ScriptScope and this lets hosts examine the state after code execution

         o public object Execute(string code)

• ScriptScopes has members to support operations on variables like set, edit, remove, clear etc.

o    public bool ContainsVariable(string name)

o    public object GetVariable(string name)

o    public void SetVariable(string name, object value)

o    public bool RemoveVariable(string name)

o    public void ClearVariables()

In addition to the above items, the spec also contains details about each of the method defined in this type and their arguments.