Expose Migrondi as a library about migrondi HOT 9 OPEN

#28 has been merged and it includesthe facilities to use migrondi as a library, I will try to get a sample of a prototype using @JordanMarr 's SqlHydra.Query to re-take the fsx scripts it will also help me test the public API and see if it's actually usable

from migrondi.

On second thought, I just noticed that my naive toEmbeddedSql fn would need to do a lot more work to properly embed different data types in a db provider agnostic way: strings need to be wrapped with single or double quotes depending on provider, etc.
Browsing through the SqlKata issues repo, I don't see any built-in functionality to do this.

So I think your original idea of just getting a list of SqlKata.Query objects would be the best. You can easily convert a SqlKata.Query object into command on your side.

Here's the updated version with some sample inserts included:

from migrondi.

FYI, I just pushed v0.200.1 with the Kata.ToQuery helpers.

from migrondi.

I'm about to start with this actually, I think for the moment I just want to be sure I can pull .fsx scripts just like I used to do on the old branch, I'll get the queries and build a command to execute them, very very close to what you have there, I'm not sure if the Kata.ToQuery is needed yet, but I do appreciate the effort!
we could actually use that to create an "eject" kind of thing where you can emit all of the migrations in standard SQL (or even transform them between languages) and use the default migrondi mechanisms

from migrondi.

Since the various query builders (select, insert, update and delete) all have different return types, I am in the process of adding a helper to transform a builder specific query spec to a SqlKata.Query, and another helper to turn a SqlKata.Query into an embedded SQL string. I think this would give you the flexibility you need for creating a clean list of migrations.

This is what I have so far.

from migrondi.

Yeah looks like the last one might do the trick, I'm also wary that this is going to run inside a fsx script so not sure how that will turn out specially if you have "#r" usings at the top performance might not be that great

from migrondi.

Since migrations would probably be run as part of a CI build, I can't imagine that a few seconds here or there would be that big of deal. Or do you think it would be longer than that?

But if performance is a concern, you could create a separate Migrondi package that would allow running it as its own executable.

Pros:

• it would be easy to add a migration fsproj with migration "scripts-as-code"
• this package could share some of the existing code used by your dotnet tool
  Cons:
• would be a separate package to create

For some of my projects I use a FAKE build .fsx, but recently I have begun skipping using the FAKE dotnet tool and have instead been creating a FAKE build console .fsproj. For some reason this seems easier to me because I can just pull it into my project via NuGet as opposed to mucking around with the dotnet command line tools.

from migrondi.

More thoughts on creating a list of migrations-as-code...
I can imagine you creating a series of "adapter" functions that transform the various inputs to some sort of a MigrationScript spec.
For example:

    let seedErrorsTable: SqlKata.Query list = 
        [ 
            for record in sampleErrors do
                insert {
                    into table<dbo.ErrorLog>
                    entity record
                }
                |> Kata.ToQuery 
            
            update {
                for e in table<dbo.ErrorLog> do
                set e.ErrorMessage "Unauthorized"
                where (e.ErrorNumber = 401)
            }
            |> Kata.ToQuery

            update {
                for e in table<dbo.ErrorLog> do
                set e.ErrorMessage "Resource Not Found"
                where (e.ErrorNumber = 404)
            }
            |> Kata.ToQuery
        ]

    let doSomethingCmd = 
        new Microsoft.Data.SqlClient.SqlCommand("UPDATE...")

    let migration = 
        [
            yield! seedErrorsTable |> List.map Script.ofSqlKataQuery
            yield! IO.DirectoryInfo("./migrations/") |> Script.ofMigrationFolder
            IO.FileInfo("./scripts/do_stuff.sql") |> Script.ofSqlFile
            doSomethingCmd |> Script.ofCommand
        ]

from migrondi.

TBH, I have used SSDT for my last few big projects with no migration, so I don't have enough experience using migrations to know if my suggestions make sense. So whatever you think is best, I defer to your judgement!

from migrondi.