Specify database name

[gareththackeray]

Hi Khalid,

Am I missing something here or is there no way of specifying the database name?

Thanks,

Gaz

[khalidabuhakmeh]

You can specify the database name in the connection string. Additionally, you can use an IoC container to build the the DocumentStore and pass it in to a Migration.

        public virtual void Setup(IDocumentStore documentStore)
        {
            DocumentStore = documentStore;
            Alter = new Alter(documentStore);
        }

We still leverage the majority of the faculties provided by RavenDB :)

[gareththackeray]

Hmm - we choose our database when opening a session a little more explicitly than that. How would you feel about a Func<IDocumentStore, IDocumentSession> SessionCreator property on the MigrationOptions to give maximum flexibility? If the property is null it could default to the existing behaviour.

On 4 February 2014 12:48, Khalid Abuhakmeh notifications@github.com wrote:

You can specify the database name in the connection string. Additionally, you can use an IoC container to build the the DocumentStore and pass it in to a Migration.

    public virtual void Setup(IDocumentStore documentStore)
    {
        DocumentStore = documentStore;
        Alter = new Alter(documentStore);
    }

We still leverage the majority of the faculties provided by RavenDB :)

Reply to this email directly or view it on GitHubhttps://github.com/khalidabuhakmeh/RavenMigrations/issues/9#issuecomment-34055905 .

[khalidabuhakmeh]

Could you explain what your application setup is? Why does your one application have multiple databases that would rely on one migration set? Should you have two different migration sets?

[khalidabuhakmeh]

If I were you I would create your own resolver using an IoC container and then inject it to the migrations that need it. That way you don't have to modify the library. It would probably be the most flexible way of accomplishing your goal and keeping your code clean.

[gareththackeray]

There are multiple databases with different datasets, but we have only one connection string and one DocumentStore and pass the database name into the OpenSession() call.

Additionally, in order to deal with developing on feature branches with incompatible databases, I have an extra-source-code-repository config file with the potential to override the database name. I.e. a dev can change this file at will without risking accidentally committing and screwing up some other dev. So it would be nice to be able to use this code in migrations.

Another option would simply be to specify the DatabaseName on the MigrationOptions.

Wouldn't you also run into this problem with a multi-tenant setup, anyway?

On 4 February 2014 13:38, Khalid Abuhakmeh notifications@github.com wrote:

Could you explain what your application setup is? Why does your one application have multiple databases that would rely on one migration set? Should you have two different migration sets?

Reply to this email directly or view it on GitHubhttps://github.com/khalidabuhakmeh/RavenMigrations/issues/9#issuecomment-34059464 .

[khalidabuhakmeh]

The migrations only expose a DocumentStore. We leave the opening of sessions to you in each migration. The reason for this is to let you use a session or drop into database commands if you need to.

    [Migration(1)]                 
    public class First_Migration : Migration
    {

        public override void Up()
        {
            using (var session = DocumentStore.OpenSession())
            {
                session.Store(new TestDocument { Name = "Khalid Abuhakmeh" });
                session.SaveChanges();
            }
        }

        public override void Down()
        {
            DocumentStore.DatabaseCommands.DeleteByIndex(new TestDocumentIndex().IndexName, new IndexQuery());
        }
    }

So in theory if you wanted to code a dependency that gets injected into each migration you are more than free to do that. Take this code for example.

    [Migration(1)]                 
    public class First_Migration : Migration // #2
    {

       Func<IDocumentStore,IDocumentSession> _sessionCreator;

       public First_Migration(Func<IDocumentStore,IDocumentSession> sessionCreator) {
            _sessionCreator = sessionCreator ?? (ds) => DocumentStore.OpenSession();
       }

        public override void Up()
        {
            using (var session = _sessionCreator(DocumentStore))
            {
                session.Store(new TestDocument { Name = "Khalid Abuhakmeh" });
                session.SaveChanges();
            }
        }

        public override void Down()
        {
            DocumentStore.DatabaseCommands.DeleteByIndex(new TestDocumentIndex().IndexName, new IndexQuery());
        }
    }

This would accomplish what you are looking to do. Alternatively you could just reference any code to select the session in the migration.

Am I making sense?

[gareththackeray]

OK.. but what about in Alter.Collection? That just goes straight to (default) DatabaseCommands.

Also, the Runner stores the migration docs in the default db. Wouldn't it be better to store them in the database you're migrating, to make it self-consistent?

On 4 February 2014 14:06, Khalid Abuhakmeh notifications@github.com wrote:

The migrations only expose a DocumentStore. We leave the opening of sessions to you in each migration. The reason for this is to let you use a session or drop into database commands if you need to.

[Migration(1)]
public class First_Migration : Migration
{

    public override void Up()
    {
        using (var session = DocumentStore.OpenSession())
        {
            session.Store(new TestDocument { Name = "Khalid Abuhakmeh" });
            session.SaveChanges();
        }
    }

    public override void Down()
    {
        DocumentStore.DatabaseCommands.DeleteByIndex(new TestDocumentIndex().IndexName, new IndexQuery());
    }
}

So in theory if you wanted to code a dependency that gets injected into each migration you are more than free to do that. Take this code for example.

[Migration(1)]
public class First_Migration : Migration // #2
{

   Func<IDocumentStore,IDocumentSession> _sessionCreator;

   public First_Migration(Func<IDocumentStore,IDocumentSession> sessionCreator) {
        _sessionCreator = sessionCreator ?? (ds) => DocumentStore.OpenSession();
   }

    public override void Up()
    {
        using (var session = _sessionCreator(DocumentStore))
        {
            session.Store(new TestDocument { Name = "Khalid Abuhakmeh" });
            session.SaveChanges();
        }
    }

    public override void Down()
    {
        DocumentStore.DatabaseCommands.DeleteByIndex(new TestDocumentIndex().IndexName, new IndexQuery());
    }
}

This would accomplish what you are looking to do. Alternatively you could just reference any code to select the session in the migration.

Am I making sense?

Reply to this email directly or view it on GitHubhttps://github.com/khalidabuhakmeh/RavenMigrations/issues/9#issuecomment-34061754 .

[khalidabuhakmeh]

Yeah you're right about Alter and the Runner, also WaitForIndexing. Do you want to spike something that would work for you and would maintain the current behavior?

I imagine that if a Migration could take in a DatabaseName then that would solve the majority of the issues. Where that database name comes from is what I'm still not sure of.

[gareththackeray]

OK will try and do it over the next few days.

On 4 February 2014 14:26, Khalid Abuhakmeh notifications@github.com wrote:

Yeah you're right about Alter and the Runner, also WaitForIndexing. Do you want to spike something that would work for you and would maintain the current behavior?

I imagine that if a Migration could take in a DatabaseName then that would solve the majority of the issues. Where that database name comes from is what I'm still not sure of.

Reply to this email directly or view it on GitHubhttps://github.com/khalidabuhakmeh/RavenMigrations/issues/9#issuecomment-34063496 .

[khalidabuhakmeh]

Awesome, thanks for pointing it out and thanks for taking an interest. Let me know if you have any questions.

[dportzline83]

Did this issue get resolved?

[gareththackeray]

We've made it all work fine for us without any changes.

[dportzline83]

Ok, I'm closing this issue then.