Jordan Marr

Yes, you can manually edit the underlying `SqlKata.Query` and then use the HydraReader manually. For example: ```F# /// Gets the query text from the underlying SqlKata.Query. let toSql (query: SqlKata.Query)...

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...

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...

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...

FYI, I just pushed [v0.200.1](https://www.nuget.org/packages/SqlHydra.Query/0.200.1) with the `Kata.ToQuery` helpers.

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....

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...

I think I was using reserved attribute names. Changing them fixed it! ```F# [] let FluentIcon() = let _, props = LitElement.init(fun init -> init.useShadowDom

While It would be possible to have the library do nothing, I like that it is more specific about disallowing an invalid input. But I agree that in your case...

You could also skip the helper function altogether and just call the option `.Value` property when setting `entities`: ```F# let private myQuery (request : Request.MyQuery) : Async = task {...