Note: Built on #167; will rebase when merged.

@panarch not ready for merge. Any ideas on how to clean things up?

Optional feature auto-increment sounds good :)

I saw that you added optional methods in Store and StoreMut, get_generater and set_generater.
And.. it looks like you are considering SledStorage implementations to work both with auto-increment and without auto-increment.
Let's make it simple, AlterTable was simple to support as optional, but AutoIncrement might be different because it may require storage implementation code changes.
You can simply consider to run test based on..

• features = [sled-storage]
• features = [sled-storage, auto-increment]
• features = [sled-storage, alter-table, auto-increment]

Let's exclude features = [sled-storage, alter-table] requirement.

Then, you don't need to provide specific implementation patterns to users.
Some storage makers may want to use a different strategy on implementing auto increment.

Current methods, get_generater and set_generater look like providing specific pattern.

How about making this simple as possible?
something like.. only having a single trait method, you can simply make a new store trait rather than putting methods into Store and StoreMut.

pub trait AutoIncrement<T: Debug>  {
    async fn generate_id(table_name, column_name) -> Result<T>;
}

Then using this, we can only need to call generate_id on auto increment constraint column, and put that id into Row. That's all we need to do.

Preparing space for auto increment id, it is all up to storage implementation.
I like current choice to prepare new slots for auto increment, but I don't think it is good to be exposed to store interface.

(btw, little bit off the topic, you might worry about this may make INSERT query execution not to be atomic. Let's don't care about it for now, we can also restore atomic in INSERT using different pr)

Oh I just found a mistake in my prev opinion. AutoIncrement trait may not need to use T because it returns numeric id rather than key T.

This makes sense.
Will give it a go.

Hello,
Could there be an issue when loading/restoring old dumps into tables having AUTO_INC columns.
The value should be taken from the dump dataset. Other dumped tables might refer as FOREIGN KEY.

There should be some ANSI like

DO not autoinc on table(s)
Restor table(s)
DO autoinc on tables(s)

There are a set of solutions depending on supplier
How to do in gluesql

@willy610
The idea is to only auto increment when there is no value
(aside: or, still a bit of a mixed idea on whether to do this and defaults for NULLs)

Thus if you are INSERTing data, as long as the AUTO_INCREMENT column has values, it should be fine.
Is that your concern?

@KyGost
Well that sounds good.

1. Always dump the value
2. and accept new value on insert
3. but no change on update!?

I did had some concerns some years ago on a complex system.

(Perhaps I was confused by the Export/Import options in the tool phpmyadmin.php.
Your comment on aside: is still actual )

@willy610 yup, it only ever bothers generating a value if it doesn't have one.

As for UPDATE depends on whether we do defaults for NULL or not. If we do, using NULL would generate a new value.
In all other UPDATE circumstances however, we just leave the value unchanged :-)

I've spent a little too long from this issue and don't remember what was in my way.

I've rebased it to main and it seems to be working. Moving out of draft.

This PR has become a bit of a mess. Will make a new one.