Ideal way to load all indexes in RavenDB 4.0

[Ciel]

Is there a suggested, or ideal way to load all of your indexes into RavenDB 4.0? This is currently what I've got, and it works for normal indexes, but it fails on MultiMap indexes - anything that inherits from AbstractMultiMapIndexCreationTask<T>.

[Oren Eini (Ayende Rahien)]

IndexCreation.CreateIndexes() is there. 

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Wed, Dec 13, 2017 at 4:16 AM, Ciel <stacey.ci...@gmail.com> wrote:

Is there a suggested, or ideal way to load all of your indexes into RavenDB 4.0? This is currently what I've got, and it works for normal indexes, but it fails on MultiMap indexes - anything that inherits from AbstractMultiMapIndexCreationTask<T>.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ciel]

The problem is that trying to use

```
    .Select(Activator.CreateInstance)
    .Cast<AbstractIndexCreationTask>()
```

Fails on `AbstractMultiMapIndexCreationTask`, though. So I'm having trouble getting the instances of all indexes to pass though the create method.

On Wed, Dec 13, 2017, 3:44 AM Oren Eini (Ayende Rahien) <aye...@ayende.com> wrote:

IndexCreation.CreateIndexes() is there. 

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Wed, Dec 13, 2017 at 4:16 AM, Ciel <stacey.ci...@gmail.com> wrote:

Is there a suggested, or ideal way to load all of your indexes into RavenDB 4.0? This is currently what I've got, and it works for normal indexes, but it fails on MultiMap indexes - anything that inherits from AbstractMultiMapIndexCreationTask<T>.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/7T1v1T4F6us/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ravendb+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

Why are you doing it this way? The IndexCreation handles all of that for you

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Thu, Dec 14, 2017 at 3:50 AM, Ciel <stacey.ci...@gmail.com> wrote:

The problem is that trying to use

```
    .Select(Activator.CreateInstance)
    .Cast<AbstractIndexCreationTask>()
```

Fails on `AbstractMultiMapIndexCreationTask`, though. So I'm having trouble getting the instances of all indexes to pass though the create method.

On Wed, Dec 13, 2017, 3:44 AM Oren Eini (Ayende Rahien) <aye...@ayende.com> wrote:

IndexCreation.CreateIndexes() is there. 

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Wed, Dec 13, 2017 at 4:16 AM, Ciel <stacey.ci...@gmail.com> wrote:

Is there a suggested, or ideal way to load all of your indexes into RavenDB 4.0? This is currently what I've got, and it works for normal indexes, but it fails on MultiMap indexes - anything that inherits from AbstractMultiMapIndexCreationTask<T>.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/7T1v1T4F6us/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ravendb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[Ciel]

When you asked this more than once, I stopped to look at my code more thoroughly to see what you were talking about, because I thought I had searched long and hard for a built in way to do it. It was not until I was forced to reformat my computer yesterday did I truly discover what I was doing wrong.

I am using the new JetBrains "Rider" IDE for C# (which is great), but I am on an EAP ("Early Access Preview") nightly build. When I would put in 

IndexCreation.CreateIndexes( ...

I would only get one of the signatures popping up;

IEnumerable<AbstractIndexCreationTask> indexes, IDocumentStore store, DocumentConventions conventions = null, string database = null

This was my problem. I was having a difficult time getting the collection of `AbstractIndexCreationTask` because it kept throwing an error when it hit `AbstractMultiMapIndexCreationTask` indexes. It turns out, there was a bug in the (excruciatingly specific) build of the Rider IDE I was using where it was only showing the last override for a given specific method. Taking a look right at the source reveals that as well;

So I was very confused why you kept suggesting that method.

Due to an error I made with something else, I was forced to do a full system reformat, and when I installed the newer version of the Rider IDE, this bug had been fixed and I began to see the full list of signatures properly. This is inevitably what led me to drill into the code and see what had happened (and subsequently, I loaded up a Hyper-V VM to try the previous EAP that had the error to confirm this)

Now that I'm seeing the signatures correctly, it works fine to use this;

Thank you so much for taking the time to point it out to me!