Jacob Montgomery

If things get too bad you can always blackhole the IP range temporarily or permanently - usually after so many failed connections the bots will go away...

ip route add blackhole IP/{8/24/32} changing ip/{options} to fit the range you want to blackhole... so you could do something like ip route add blackhole 203.160.52.0/24 and that would block all requests coming in from 203.160.52.0 - 255

When I experience high hits like this, I will usually tail -f the logs and monitor the IP addresses, as they roll through I'll keep adding them to the blackhole list.

Hmm, this I'm not sure of. Someone with more knowledge of transactions and/or validations may have a solution if it's even possible...

From my understanding, a transaction gets rolled back as soon as there are any exceptions thrown. This is why when you have 3 validations, it will roll back the very first time an exception is thrown, so the remaining 2 validations aren't even ran (I think at least, but I could be wrong here).

You may end up having to make a custom validation to check the data before it's even handed over to the transaction. This should be fine to do if it's simple validations, like presence or data type. However, if you have to check for uniqueness then it would result in extra hit to the DB and wouldn't necessarily protect you from a race condition.

Oh sweet, glad that worked out!!

I'm not completely sure since I have very limited experience with making an API with Rails, but could your problem be solved by wrapping your find/save/update in a transaction?
Something like:

ActiveRecord::Base.transaction do
  api_fields.each do |api_field|
    content_model_field = @content_entry.content_model_fields.where(field_id: api_field).first
    content_entry_field = @content_entry.content_entry_fields.where(content_model_field_id:: content_model_field.id).first_or_create

    content_entry_field.update_attributes(value: params[:entryData][:fields][api_field.to_sym])
  end
end

http://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html
No clue if this would actually work, just throwing it out there =D

Sweet! That was a bit of a roller coaster! :)

If you're going to be working on this for awhile and think you'll need help often, it would help to make a repo that could be cloned and ran locally... if that's an option of course. If so let me know, I'd love to take a deeper look at what you're doing with this project.

To make it shorter, I believe you can do this:

@venues = params[:venue_ids]
@variants = params[:variant_ids]

@venues.each do |v|
  @variants.each do |pv|
    @back_bar = BackBar.new(venue_id: v, product_variant_id: pv, product_id: params[:product_id])
    @back_bar.save!
  end
end

If you have validations, then as far as I'm aware you can't do the bulk saving (mass insert) since it still has to check each object on save. If anyone has knowledge how to do this mass insert with validation I'd love to know!

Ack, wait - this isn't right either. This is why it's so hard to trouble shoot stuff without being able to run the code - simple stuff is easy to overlook =D

@venues = params[:venue_ids]
@variants = params[:variant_ids]

@venues.each do |v|
  @variants.each do |pv|
    @back_bar = BackBar.new
    @back_bar.venue_id = v
    @back_bar.product_variant_id = pv
    @back_bar.product_id = params[:product_id]
    @back_bar.save!
  end
end

Have to move @back_bar.venue_id = v down into the @variants loop since we moved @back_bar = BackBar.new down as well.

Hard for me to say which way is better - I prefer my way just because I understand it and I like service objects :D but their suggestion may be valid or better. Although I am a little thrown off by their methodology... doesn't feel very "Railsy"

I should have refreshed myself on your original question and subsequent posts... so I'm going to back track a little. Using your original .each way (below) - did it work as expected?

@back_bar = BackBar.new
@venues = params[:venue_ids]
@variants = params[:variant_ids]

@venues.each do |v|
  @back_bar.venue_id = v

  @variants.each do |pv|
    @back_bar.product_variant_id = pv
    @back_bar.product_id = params[:product_id]
    @backbar.save!
  end
end

If not, then I bet your problem is calling BackBar.new outside of your loops, so it's only be instantiated once. You'd need to do this instead:

@venues = params[:venue_ids]
@variants = params[:variant_ids]

@venues.each do |v|
  @back_bar.venue_id = v

  @variants.each do |pv|
    @back_bar = BackBar.new
    @back_bar.product_variant_id = pv
    @back_bar.product_id = params[:product_id]
    @back_bar.save!
  end
end

Let me know if this works now. If so, then you can look into making it more robust / efficient.

Hard to diagnose without seeing exactly what you have, but you may want to byebug in a few places to see what the data looks like at each step and do kind of a "duh" check to see if it makes sense...

to_save_array = []

@venues.each do |v|
  @back_bar.venue_id = v

  @variants.each do |pv|
    @back_bar.product_variant_id = pv
    @back_bar.product_id = params[:product_id]
    to_save_array << @back_bar
    byebug
  end
  byebug
end

byebug
BackBar.save!(to_save_array)

For reference, check out this gist => https://gist.github.com/nanosplit/a42d1c18b5eca01654563cfb3bb8c22f
It's setup a bit different than what I showed above since I can't do a mass save (model has validations) but shows how I'm making my own set of params to then create a new object from them. So you may try mimicking this setup to see if you can at least get it to property save each unique record, then worry about making it more efficient later.

Yeah, basically after each iteration, @back_bar is a new BackBar object that has values based on what you passed to it. So you can now do something like:

to_save_array = []

@venues.each do |v|
  @back_bar.venue_id = v

  @variants.each do |pv|
    @back_bar.product_variant_id = pv
    @back_bar.product_id = params[:product_id]
    to_save_array << @back_bar
  end
end

BackBar.save!(to_save_array)

You may need to tinker with the save part some, I didn't test this but this should be what's needed if I recall correctly since save is able to take a single object or an array of objects. Also note I didn't do this in a transaction, while not required it can help, but I'd suggest getting this working first before adding the complexity of a transaction. Let me know if you have further problems and I'll take a look at what I did in one of my projects.

Oops, I just noticed I had an error in my original post:

def some_function
  invoices = params[:invoices]
end

should be

def some_function
  invoices = params[:invoice_ids]
end

So when you say "I want to create a new row for each venue and variant.", in your example you'd end up with a total of 2 records, but if you had 2 variant_id's, then you'd have a total of 4 records?

If this is the case then as far as I am aware your way is fine, there might be a sleeker or more "Railsy" way of doing it that someone else could share. You may consider building a hash/array of new BackBar objects then do a mass save in a transaction. This would allow you to handle any errors during the transaction more elegantly.

I could have sworn Chris had a video that talked about this but I'm not able to find it...

If you search for rails multiple checkboxes you'll get quite a few results and there's a Railscast episode that covers it really well. I'm not sure if it's kosher to post another video so I'll let you handle the Googling :)

But the basics are in your form you'll need something like

<% @invoices.each do |invoice| %>
  <%= check_box_tag "invoice_ids[]", invoice.id %>
<% end %>

which submits to a method in your controller that then, in this case would:

def some_function
  invoices = params[:invoices]
end

From there, do whatever you want with the array of invoice id's

Hope it helps!

I haven't done this personally but I have some very similar scenarios and I think that if I were doing it, I'd setup a form that has all the options for your user to select which submits their selections to a custom function that will take that input, run my queries, and generate an array or hash to then pass to the csv save function.

Sweet, I'll have to play around with it, I love a good editor! :)

Did you ever mess with Summernote? http://summernote.org/examples/#hint-for-mention
They support mentions out the box it looks like. I use it on a site and have had no real issues so far.

Anywho - thanks again, and great job!!

Woah, very clean!

Think you'll be sharing some of the techniques you used? I'm digging this WYSIWYG editor!

Thanks Chris! :)

Hmm, markdown isn't parsing for me even though it's showing up in the preview just fine... oh well, this is what I was trying to post as my example:

https://gist.github.com/nanosplit/b50241d66947fbcae3a1020d1f94ab8a

Sorry to spam! :)

Lol naming can be a major PITA... just last night I spent a few hours just renaming things to be a little more future proof.

If you're able to, take some time to build prototypes and do proof of concepts. This will help clear up some of the naming issues that happen when first starting a project. Often you don't know what really makes sense until much further along in the project but by that time it's too late or a major undertaking to rename.

An episode that digs into the associations would be great! Just last week I finally figured out some of the magic in associations, the moment I realized you can designate your own primary / foreign keys and even name it however you'd like was one of the happiest moments in my life!

class Agent < ActiveRecord::Base
  has_many :ar_listed, class_name: 'Abor::AborRetsResi', primary_key: 'agent_id', foreign_key: 'list_agent_mlsid'
end

#this lets me do:
@agent_listed_properties = current_agent.ar_listed

#which returns all the listed properties that agent has! Before, I would have had to do something like:
@agent_listed_properties = Abor::AborRetsResi.where(list_agent_mlsid: current_agent.agent_id)

Of course this may not be the best way to approach this, but seeing how this all works was really eye opening!

Hah, the devil is in the details... naming can be incredibly important. Your code is telling a story to other developers, so using descriptive names can go a really long way.

I was just reading more into the HABTM associations and they show to use the names of the two associated tables to make the name of the join table... so in your case this would be :venues_products. It's a little weird to say out loud but at least the name instantly tells you that it has something to do with venues and products.

This was an interesting problem, thanks for the challenge Alan, and thanks Chris for the nice solution! :)

You may want to check out the has_and_belongs_to_many association

http://guides.rubyonrails.org/association_basics.html#choosing-between-has-many-through-and-has-and-belongs-to-many

class BackOffice < ActiveRecord::Base
  has_and_belongs_to_many :products
end

class Product < ActiveRecord::Base
  has_and_belongs_to_many :back_offices
end

Again, Chris may be able to clear this up more... I haven't had much personal experience with HABTM so there could be some catches I'm unaware of.

It kind of depends on products in this case. Will a BackBar ever have more than 1 product? And will a product ever belong to multiple back_bars?

If your BackBar will only ever have 1 product associated with it then you can store the product_id in the BackBar table. However, if a single BackBar can have multiple products, then you will have to let the products table store the back_bar_id so that Rails will know what products belong to what back_bars. The whole "Rails Magic" thing really is just letting Rails know which foreign_keys it has to look for in order to retrieve the records.

Just a thought, but would a :through association work better here? Something like:

http://guides.rubyonrails.org/association_basics.html#the-has-many-through-association

class Venue < ActiveRecord::Base
  has_many :back_offices
  has_many :products, through: :back_offices
end

class BackOffice < ActiveRecord::Base
  belongs_to :venue
  belongs_to :product
end

class Product < ActiveRecord::Base
  has_many :back_offices
  has_many :venues, through: :back_offices
end

I have no idea if this would work correctly for you but may be worth tinkering with unless Chris can say definitively one way or another?