Hello, Sequel admirers :) Even though I've been using Sequel for several years, for all that time I've been using the migrations framework bundled with ActiveRecord through another project of mine called active_record_migrations:
https://github.com/rosenfeld/active_record_migrations It works well, it's well documented and has suited my needs so far. But now that I'm considering creating new projects after a long while, I wanted to work in a scaffold integrating Roda, Sequel, Webpack, React-like libraries with smaller footprint (think of Dio.js or Inferno.js), Rodauth, automated deployment, distributed logging (think of fluentd), security concerns, monitoring, error tracking, performance tracking, analytics, support for mobile devices, support for IE11, client-side lazy code loading, client-side routing and so much more. The more I think about this project the more I see how hard it is to start a new project these days from scratch and I can appreciate more the effort made by frameworks such as Rails in trying to provide good defaults out-of-the-box so that someone would be able to start more quickly. Just like I also appreciate efforts like Heroku, but I think Heroku is still missing blue-green (or canary if you prefer) deployment. Anyway, I'm not really happy with Rails + Heroku either, so I guess I'll have to keep investing a lot of effort in this new project starter I'm working in. It happens that I had to take a pause on it once I realized I wasn't comfortable with depending on full railties just to be able to manage the migrations through active_record_migrations. It didn't feel right, specially for a new project that wouldn't even use ActiveRecord. I knew it would be a lot of effort to bring the basics that is already built in and battle tested from ActiveRecord migrations to the Sequel equivalent version, so I was never able to justify this move before, but this time I decided to spend some time on it. Also, I wanted to be able to use Sequel datasets in some migrations. I guess I'll miss the "reversible" block provided by ActiveRecord migrations, which is not supported by Sequel, but other than that I think switching to Sequel migrations will be a good thing. So, several hours later (about 2 days focusing in this project), I think I was able to get something with features enough to make it useful. I'd love to get your feedback about the project: https://github.com/rosenfeld/sequel_tools It's late, so I'm sorry if the documentation and examples are not very good at this point, but it was built to be easy to extend, either through custom code or external gems and, of course, pull requests to the project itself are welcomed, but you shouldn't have to wait for them to be merged to be able to take advantage of the gem immediately. My idea is to try to close the gap regarding support for Migrations and related database operations through integration with Rake. Even though the test suite basically tests the integration with Rake, it should be also possible to use those tools through other interfaces, such as command lines. There's nothing really tied to Rake in the base build block. So, instead of everyone spending a lot of time to get some very basic Rake tasks such as migrate and rollback, I decided to take it a step further and implement many of the tasks which I find important for managing databases. It should be easy to support multiple databases using those tools, either because they belong to separate environments or because the application uses many databases for a given environment, it shouldn't matter. Here are some of the currently implemented tasks: - create the database; - drop the database; - migrate (optionally to a given version, or latest if not informed); - generate a migration file (timestamp based only); - status (which migrations are applied but missing locally and which are not yet applied to the database); - version (show current version / last applied migration); - rollback last applied migration which is present in the migrations path; - run a given migration up block if it hasn't been applied yet; - run a given migration down block if it hasn't been applied yet; - redo: runs a given migration down and up, which is useful when writing some complex migrations; - dump schema to schema.sql (configurable, can happen automatically upon migration - implemented just for PostgreSQL for now, by calling pg_dump, but should be easy to extend to support other databases: PRs are welcomed or complementar gems); - load from schema; - support for seeds.rb; - reset by re-running all migrations over a new database and running the seeds if availabe; - setup by loading the saved schema dump in a new database and running the seeds if availble; I decided not to support the Integer based migrations at this point as I can't see any drawbacks of timestamp based migrations that would be addressed by the Integer strategy while there are many problems with the Integer strategy even if there's a single developer working in the project. I'm open to discuss this with anyone that thinks that could convince me otherwise that supporting Integer based migrations would add something to the table. It's just that it's more code to maintain and test and I'm not willing to do that unless there is indeed some advantage over using timestamp-based migrations. The project also allows missing migration files, since I find it useful specially when reviewing multiple branches, dealing with independent migrations. I don't think it's a good idea to work with a Ruby format for storing the current schema, as a lot of things are specific to the database vendor. I never used the Ruby vendor-independent format in all those years, but if you think you'd value such a feature in case you just use the basics when desigining the tables and want your project to support multiple database vendors, then go ahead and either send a Pull Request to make it configurable, or create a complementar gem to add that feature and I can link to it in the documentation. I'd love to get some feedback regarding what the Sequel community would think about it. I'd love for us to get to some consensus on what should be the de facto solution for managing Sequel migrations in a somewhat feature-complete fashion and would love to get the community help on making such de facto solution happen to the best interest of we, Sequel happy (and sometimes frustrated by the lack of proper tooling around migrations - no more) users ;) Please take a look at how the code looks like and I hope you find it easy to extend to your own needs. Any suggestions and feedbacks are very welcome, specially now that the project is new and we can change a lot before it gets a stable API. May I count with your help? ;) Cheers, Rodrigo. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
