I'm not really sure what the best command name to generate the migration. I'm open to suggestions if anyone has any.

Hi, and thanks for starting this. I would suggest update-schema?

So, I have been thinking about the auto generated migration and I am wondering whether this is something we want to do. Some people will prefer to have their migrations written in rust, others will prefer sql. Even then, there is the difference between versioned and unversioned migrations. Should we just have the ability to generate all of these different types of migrations, or should there just be a note in the changelog and readme stating to migrate the table?

Or maybe instead of creating a migration, we could just have refinery take care of it? Similar to how refinery will automatically create the schema table for you.

Or maybe instead of creating a migration, we could just have refinery take care of it? Similar to how refinery will automatically create the schema table for you.

can that be done with sql standard? If so yeah definitely, thanks!

So this is the functionality that you would like the keep? How would I go about applying the "older" migrations?

sorry, did not understand the question. How does this affect older migrations?

Really sorry about this. I don't really understand how I managed it, but I meant to reply to the most recent comment on #83. Let me repost question there just so that everything is clear.

ON 32 bit systems this should fallback to characters, or should these longer 'version' number schemes just be character/String consistently.

I also wonder if we wouldn't have less headaches on smaller platforms if we just used usize and fall back to char/String when the versions number is 'too-big' for the system refinery is running on?

ON 32 bit systems this should fallback to characters, or should these longer 'version' number schemes just be character/String consistently.

Bitness should not matter as long as the database supports INT8, which seems like a reasonable baseline requirement to be usable as a database anyway.

I'm super excited about this change because I just wrote unfortunate code that puts a Unix epoch time into the version number.

Actually, since Refinery checksums are 64 bits, it already requires that the DB can store a 64 bit integer.

going to close this out of lack of activity, feel free to re-open if you or anyone wants to work on this again.
Thanks!

@jxs What's missing for this to be merged?

Would a feature flag be an acceptable solution to not risk breaking any existing dependent code out there?

Hi @mbrgm this PR was stale for more than a year before being closed, so I don't know what was missing and how would this PR be compatible with the current codebase but feel free to fork the branch and work on the feature, if you want any guidance ping me.
Cheers :)