There appear to be at least four repos on github that claim to tie in Sequel to the latest Rails 3 beta.
Has anyone successfully replaced ActiveRecord with Sequel in a Rails 3 project? Could you provide some hints on how to best go about it?
I'm interested in starting a new project on Rails 3 and trying to get off on the right foot: ideally sequel, minitest, and omniauth (with devise if it won't be painful). I know this is not the blessed stack, but these gems appeal to my spidey sense. I'm looking for any advice that will help me work through any gem issues and conflicts.
I've used Sequel with Rails 2 and 3. If you aren't using any of the ActiveRecord integration features, it's actually easy even with Rails 2, you just have to set up the Sequel database connection manually either in an environment file (environment.rb or environments/*.rb), or in an initializer. Your Sequel models still go in app/models/.
With Rails 3 and the Sequel active_model plugin, integration should work fine from a code perspective. Most of what the github repos do is deal with things like rake tasks and generators, which while nice, are not actually necessary.
Because sequel-rails no longer seems to be maintained, I looked for forks. The TalentBox version seems to be promising and is actively maintained.
I have to add however, the migrations (rake db:migrate and the like) seem to be somewhat broken. There are some patches in my fork, see the iblue/sequel-rails production branch. I will eventually push them to talentbox, when the are stable.
EDIT: TalentBox is working quite fine now.
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
Currently I am writing a Ruby on Rails application, and I am using Gems, however sometimes I feel that Gems are not as flexible as I want them to be. To make them more flexible. Should I
Fork them on github, and customize it, but this still present the challenging of managing everything.
or
Strip and merge the code of the gem to the main application? This will allow further customization of the gem. This would be for situations where a Gem require another Gem's functionality.
or is there a better way of doing this?
Thanks
B
Choice A is the better answer for a number of reasons.
You get to merge in security updates, enhancements, and bug fixes easily.
Your changes may get merged into the core--in fact, consider if you could implement them in such a way as they live alongside the core functionality as options. If this happens, you have the ultimate win--nothing to maintain, and you can retire your fork.
Others can benefit from your changes.
Your project's footprint is kept smaller and focused by keeping the gem code isolated.
You'll have something to add to your Github "resume."
If its some kind if not so popular gem or "bicycle" from some previous studio or developer who started project(in my case).
I prefer deprecate this gem's and move code into project,
for example they have c***la-deploy - it's just wrapper to Capistrano 2 with own methods))) - I just delete it and rewrite on last Capistrano 3
Than that have own "CMS" c***la-cms where they wrap standard form_for or simple_form with name "twitter_form_for" ? - fist of all I start try to find gem who use this name, and than find in dependency gem's ...
Its take a lot of time for new developer involve in project - better move to standard rails methods/heplers
But anyway i understand for a what this studio do that - its just vendor lock and for client more hard to move out from them to another developers.
For example for startup its bad to use a lot of dependencies and if it's just simple website - dose not matter.
I am developing a Ruby gem, Ampere, that acts as an ORM for the Redis database. I am trying to shore up its Rails integration, and was able to tie in an initializer and console hook, but my generators do not work yet. I have a generator, ampere:config that installs a default configuration YAML file, and a replacement for the model generator as well.
When I install my gem into a testing Rails app, the ampere:config generator shows up in the list when I run rails generate on the command line, but when I type rails g ampere:config, I get:
Could not find generator ampere:config.
and nothing else. My generator lives in "lib/rails/generators/config/" within the gem, and clearly Rails knows about it since it showed up in the rails g list, but something's not right. If anyone can help or knows of some better documentation for this than the Rails Guides, which are sparse to say the least, it'd be much appreciated.
Ok so I finally got this. For the generators to work, they have to call source_root with the relative path of their templates, and they have to live in lib/rails/generators/your_gem_name/, then the directory structure in your_gem_name/ is what you'd expect from reading the documentation (or running rails g generator in a Rails project).
The documentation is not very clear about this, so it was a bit confusing, but after looking at a few examples I tried this and it worked.
I have this rails Application which uses salesforce App. I want to know if there are any gem and tutorials to build Salesforce App in rails easily. I found this rforcedotcom gem but it lacks tutorial for Rails 3.
The current standard gem is the databasedotcom gem, which is updated fairly actively and officially endorsed by Salesforce.
There is also the asf-rest-adapter gem (which has a dependency on asf-soap-adapter) by Ray Gao which I have running in a number of apps, and works quite well.
There's yet another gem out now called Restforce.
The author bills it as "lighter weight" with "greater flexibility and more advanced functionality" than the databasedotcom gem (and he should know -- he worked on the that gem too).
Another alternative is to use Active Force that uses RestForce as a backend and provides an ActiveRecord like interface. It also have some generators to get up and running faster.
I googled for the the plugin/gem to do the ActiveRecord versioning for Rails3.
But all I've got is not compatible for Rails3. I even searched in RailsPlugins.org too, but no luck.
Do you know any that is Rails3 ready?
There is also http://github.com/airblade/paper_trail
The acts_as_versioned gem seems to not officially support rails3 yet, but this guy has forked the project and created a rails3 branch. Take a look at it.