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 [email protected] 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//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 [email protected] 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//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 [email protected] 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//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 [email protected] 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//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.