Chris Oliver

Yeah, I guess if the reindex on a model clears the index before adding in the records, then that won't work.

However, then you should be able to go through each record and call reindex on it individually. That I know won't clear the index and so you could compile a full index of all the product records after looping through the tenants. It might be a tad slower on the initial index, but that's only going to happen the first time you index the full database. From then on, you'll be indexing things inside the app when changes are made so it should stay in sync just fine. And you won't need to do any of that department unscoped querying either. You can just access through the record directly.

On the unscoped part, you aren't calling a block there so I don't think you won't be running into that Rails bug.

It's one of those things that needs to be pretty customizable at times because sometimes you might have nested routes and want to match the parent or something, not the controller or action.

There's a nifty little gem I noticed in the answers there. https://github.com/comfy/active_link_to Looks like it would do a pretty good job allowing you to match most all of the variations you might need.

Hmm, I don't see what query block you're referring to? The unscoped method you use doesn't have a block and the issue more just stems from indexing the database where the tenant isn't set.

It looks like you've got the correct url for using the gem from github, although I don't think that's your problem. I don't see anywhere this is calling a block on the query, and your real issue is still probably the same as before. You're basically indexing but no tenant was ever set.

I think the solution for you is to build your own index rake task. You'd loop through each tenant, set the Apartment Tenant, and then index each of the records inside of it (rather than in bulk). Not sure why I didn't think of that before.

Based off https://www.tiagoamaro.com.br/2014/12/11/multi-tenancy-with-searchkick/ you could do something like this:

namespace :searchkick do
  desc 'Reindex all models on all tenants'
  task reindex_tenants: :environment do
    Rails.application.eager_load!

    Apartment::Tenant.each do |schema|
      Apartment::Tenant.switch!(schema)
      Searchkick.models.each do |model|
        puts "Reindexing #{model.name} on #{schema}"
        model.reindex
      end
    end
  end
end

This isn't modified from his code, except that you're not specifying separate indexes. This will set the tenant for each, it will find all the indexed models, and then it will also go and query for those records that are available. It'll do this once for each Tenant, which means it will find different sets of Product and Department records each time.

You will probably want to go back to using department_name: department.name, because you'll be in side the tenant this way. I believe this should do what you need because it's properly setting the tenant. Curious to see if that works for you.

You might need to set the URL on the form then so that it takes you to the index action. The search form may just normally only apply to the current url, I'm not sure.

Also that's a great idea. Like highlighting a link in the nav when you're on a certain controller right?

I'm kind of surprised that worked, but I guess there was something going on between the versions of Bundler that were local and previously installed in production. We both learned something new today. :) I'll have to keep this in mind as I'm sure I'm going to run into this as well sometime soon I bet.

And thanks man! Doing what I can, but it's just as much you and everyone else in the community who keeps it going, so thank you! 🙌

Super interesting bug there, especially since you aren't the only one. Potentially you need to upgrade your version of bundler? Let me know when you figure out a solution!

Hey Lance,

Interesting problem, I haven't actually run into this before. What does your Gemfile and Gemfile.lock look like for Nokogiri?

Sounds like you checked pretty much everything! That's all the things I can think of (and more) so I wonder what's up with that.

One last thing you might check is this: https://github.com/ruckus/active-record-query-trace which should help you find the query based on the line number. Maybe it was something obvious we're overlooking.

Nothing too much. All you need to do is specify the @q variable so the search form knows what model it's searching. The results will go to your index action so there's nothing much you need to do here.

def show
    @q = Post.ransack(params[:q])
end

Welp, that looks correct as well. Somewhere you've got a query that it's hitting that doesn't seem to be the line in your show action there. Might take some more debugging to find it, but your code looks correct right now.

Ideally it's better to pass in only the ID. If the record was deleted before the job runs, you can safely quit if you can't find the record assuming it was deleted.

Now I believe that if you pass in an ActiveRecord job to ActiveJob, it will transform it to a GlobalID (https://github.com/rails/gl... / http://edgeguides.rubyonrai... which is a representation of the ID and class name so that you don't have to specifically pass the ID.

If you use Sidekiq, etc directly without ActiveJob it is going to try using that object which is why they recommend using the ID specifically.

ActiveJob + Global ID should look up the record once the job starts (you should see this in the logs) which will make running those jobs safe.

Hey Thomas,

It sounds like you might not be skipping the default before_action :set_product for show which would trip this error because the query definitely shows it wants not-deleted records. My guess would be that before_action is being run before it gets to your show action and disabling that would let your code here run which should work great. 👍

Absolutely! You need to do some interesting things for this, but I've built some JS embeds in the past. They're pretty fun.

For the most part you need to build a separate Javascript file (and stylesheet) that the users will embed and pass their custom data into (like your Google Analytics ID for example). The JS will need to run cross-origin which means that it may run on GoRails.com but it's code coming from Google analytics' domain and therefore it must be safe to send data to their domain. You'll need to read up on https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS and https://github.com/cyu/rack-cors in order to make the cross origin stuff work nicely.

They're probably not technically APIs, their more JS libraries you're building, but they will hit URLs in your app, that might be APIs. Since it's all your own JS, it's not really an API because an API is generally for other developers to consume, not yourself. It's a gray area because it's your code running on someone else's website though.

Hey Stan,

I would say either do client side or server side generation of colors. Server side, you could save a "color" attribute on the user that's an RGB version of their username so you only have to generate it when they sign up. You can pass that value over the websocket and use it for rendering of messages

If you went with the client side, you could have it generate the colors on all the existing messages on the page (might need to add a data attribute for the username) and then apply the colors to the existing messages on page load, and then add it to the new messages afterwards. You can just simply store those on the style="" attribute on the span around the username so that it's added directly to the record.

Either approach would work fine. The client side one is more likely to be simpler and less data intensive because it can generate colors on the fly without storing them. I would probably go with this approach personally.

Absolutely. Some WebRTC stuff is on the agenda, but not for a little while. I'm really interested in checking out Twilio's WebRTC functionality. First gotta cover a handful of other topics like APIs, but that'll be coming after those things!

Hey Brian,

For the most part you're going to just want to replace the Post.all and Post.where part with Ransack. You'd ideally pass in the category in to Ransack search instead as q[category_id_eq] in your UI.

Then you can say:

def index
  @q = Post.ransack(params[:q])
  @posts = @q.result(distinct: true).order(created_at: :desc)

  if params[:category].blank?
    @posts=@posts.paginate(:page => params[:page], per_page: 15)
  else
    @posts = @posts.paginate(:page => params[:page], per_page: 5)
  end
end

Just update your UI so that it sends over that category ID inside the q param so that Ransack can handle it correctly. If it's a link, you can change the param name there, or you can use the search form helper if it's a form you want for selecting the category. https://github.com/activerecord-hackery/ransack#ransacks-search_form_for-helper-replaces-form_for-for-creating-the-view-search-form

Right, so you'd have links to the two different delete urls like this:

<%= link_to "Soft Delete", blog_post_path(@blog_post), method: :delete %>
<%= link_to "Permanently Delete", really_destroy_blog_post_path(@blog_post), method: :delete %>

If I get some time this weekend I'll give it a try and see. I would expect that to work, but there might be some gotchas.

Basically you can take let your normal destroy action call the soft delete method. You'll always want to use that by default.

Then, if you want to add a way to permanently delete it, you can add another route like:

resources :blog_posts do
  member do
    delete :really_destroy
  end
end

And then your controller action for this new route can call @blog_post.really_destroy!

Unfortunately a lot of it is still up in the air directly from Rails. https://github.com/rails/ra... Hoping to see this start being more available soon.