MySQL connector for Ash?

Hi,

I work for a small MVNO and I’m very much interested to try using Ash in our internal devs. However I have a (probably) breaking requirement : I need to be able to connect it to our MySQL 8.0 (Actually Percona XtraDB) cluster. Is there something in the making ? I heard about that in the past, but did not found anything up to now.
I might be interested in having a try at making a MySQL connector myself, but I’m not sure where should I start ?

:wave: Work has been made in that direction, but MySQL itself has not been done. The best way to move forward with that would be to copy ash_sqlite into ash_mysql and start making modifications to get the tests passing. What will likely additionally need to happen is that the AshSql implementation will need to be expanded to account for whatever special thing isn’t supported by

Thanks for your answer. I started trying from a copy of ash_sqlite like you suggested and I’ve hit a problem that I’m not sure how to solve : 89 tests on 115 fail because :

* ** (ArgumentError) :returning is not supported in insert/insert_all by MySQL

What do you use it for ? Do you have an idea how may I work around that ?

You can try removing it, we use it to get the result of the insert to return. It could be replaced with reading the inserted record again? Does SQLite return that info automatically perhaps?

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…

1 Like

There is a fair amount of stuff in ash that depends on being able to get the results of a creation currently. So what we will have to do is add a capability for data layers, like return_from_create, and then if they can’t do that, we’ll have to disable certain capabilities, like after_action hooks.

For tables where the primary key is ecto generated (isn’t it the default in ash?), wouldn’t it be possible to “fake” the :returning option ?

Yes, we could definitely do that :slight_smile: They aren’t ecto generated, but they are generated in Ash by default. Basically requiring that all primary attributes have a default configured could get us started. Then we could support auto incrementing integers later, but require that you can’t do certain things in create actions.

Soooo… As you suggested, I copied ash_sqlite and had a first try at an ash_mysql datalayer. It is far from finished : i have 35 failures on the 115 tests that came from ash_sqlite, and several hard coded parts that need to be properly finished/rewritten.

It’s available here : GitHub - lejoko/ash_mysql

I’m having a bit of a hard time with it, since I’m an Ash rookie and in a lot of cases I’m not too sure of what would be the “right way” to do something. I’d be really happy if I could have some guiding to continue on that project because I really like Ash and would like to be able to use it at work!

1 Like

Nice! I will take a look in the next few days.

1 Like

Super!

1 Like

Warning: not ready for use! There’s still significant work to do. I hope I will be able to finish it.

1 Like

Hi, I opened a PR against ash_sql for a small non standard SQL problem, that MySQL does not support. Moreover, I’m not too sure where to talk about those things. Where would be the right place ?

Here or in the GitHub repo I imagine.