Ok, all tests that came from ash_sqlite are now passing. It should currently work almost like ash_sqlite but without upserts and only when using primary keys generated by ash. Primary keys autogenerated by MySQL (AUTO_INCREMENT) should probably also work but not for bulk insert/update. I’ve not yet added a verifier to enforce those restrictions. Up to now, I’ve worked only on making tests pass, so I’ve not really tested the module in a real app. I’m just now starting to play with it in an app in order to “feel” how it works.

Moreover, I’ve had a look at how ash_postgres does transactions (and custom errors) and it looks like it should be doable with MySQL. Hopefully I’ll be able to add it later. I’ve not yet had a serious look at aggregates.

If my tests go well (and when an official ecto_sql release include my fix) I will probably make a first release. Would you (@zachdaniel) like to have ash_mysql as an “official” part of ash ? After all, it is still mostly your code (from ash_sqlite), my changes are not the biggest part… Anyway, I’ve left almost all of the ash project “branding” that came from ash_sqlite in the repo for now. I’d be happy if it could be “absorbed” officially in the ash project. What is your view on that ? I’m not sure which way to go in this regard.

So the plan from here will essentially be:

1. wait for ecto changes to have a stable release
2. point ash_mysql at those
3. release the first version, and announce it officially.

Thank you for your excellent work!

MySQL does not have a way to return the result of an insert. It returns only the number of inserted records.

If you rely on auto generated primary keys (AUTO_INCREMENT in MySQL terms, which is the default for most people), there is a way to get it back wit a call to the LAST_INSERT_ID() function; You could then load the record back. However that would work only for an insert of a single record. For bulk inserts, that function returns only the id of the first inserted record, and there is no reliable way to get the ids of the other records (they might be guessable in simple cases, but it would break in a lot of clustering configs).

The only way around that would be to generate the primary key on the app side and load the records afterward or to not rely on that ability…