KoRMaK posted:

My one major tip: learn where your gem libs are and dig around in them. Sometimes the documentation is on the github site, but if you get into the code you'll see all sorts of helpful comments. I had to do this with attr_encrypted when we realized that it wasn't using IV and Salt. Someone forked it, made the improvement, and then it was merged back into attr_encrypted but no documentation talked about it. I eventually got into the library and started doing searches for keywords and found what I needed.

The other thing I did was made my own helper function, I extended serialize to has_many_serialized and now I can use that in my models. I was helped out by looking at how serialize is defined (seen here https://github.com/rails/rails/blob...erialization.rb )



Changing topics, I just had to wrestle with rails to get it to update one column. Doing the following resulted in no changes being sent to the db

Ruby code:

#my_things_controller.rb
def my_function
  my_thing.title[2] = params[:third_character] #replace the third character with the one sent from params
  my_thing.save
end

I tried a couple variations of that and it didn't work. I had to finally rest on using update_column

Ruby code:

def my_function
  _title = my_thing.title
  _title[2] = params[:third_character] #replace the third character with the one sent from params
  my_thing.update_column(:title, _title)
end

That's fucky as poo poo. Nearest I can tell is that the change of one character didn't make the object realize that it had changes on that column, so it didn't do an update query including that column. I watched the sql statements in the console, and the title never got touched until update_column was used.

KoRMaK posted:

Oh, okay. Thanks! Also, why? Is _title and @my_thing.title the same object in memory? I thought doing _title = @my_thing.title would create a new instance of the string. And when I set @my_thing.title = _title it would see that there was a different string set.

enraged_camel posted:

I'm working on a hobby CRUD project that allows users to upload stuff and then view their submissions.

Instead of the typical "/resources/:id" path, where id is the primary key, I'm thinking about creating a random url-safe base 64 string and associating it with each record.

My challenge: I don't want to store these strings as part of the record. I would like the lookups to still be done using the primary key.

Can I use something like Redis for this? I was thinking of a structure like { string => id } whereby during every request I feed it the string (which is the request param), find the corresponding id, and then use that id to find and display the record.

KoRMaK posted:

What is that?

big boi posted:

This is awesome, I'm going to use #blank? all over the place now.

BTW I just found this thread, looks like an awesome resource. I'm a student at the Turing School in Denver, which is like a long-form (7 mo) bootcamp for Ruby/Rails/JS. If anyone knows about anyone hiring junior devs in the Denver metro area or remotely, let me know! Otherwise I'll just be lurking and putting my two cents in occasionally.

KoRMaK posted:

If I wanted to spawn a process from my app that runs continuously, how would I do that and make sure it' stays running, or gets started again if its not? My rough draft is that I would spawn a SuckerPunch job that would just continuously run with a do while(true) loop, and sleep when it didn't have stuff to do.

Pardot posted:

The Dreamer posted:

I'm trying to randomly grab a field from a randomly selected record that is associated with another record. I see that I can do this by ordering and calling a Random function for whichever database I'm using. This is still a prototype app so I'll probably actually do this before I go to production. I found a different way to do this though and was wondering if it was actually a terrible idea. It works now but I'm not sure how it would scale over time with larger database tables.

I have 3 tables, Business, Types, and BusinessTypes. I'm doing a Business has_many Types though BusinessTypes association. What I'm trying to do right now is grab a random Business of a certain Type and grab an image url that is stored in the Business object. my current way of doing this is:

code:

type.businesses[rand(0...type.businesses.count)][:image]

Like I said this actually works but I'm just curious as to how it would scale. I know that just randomizing the order of the database files and then picking one can be really intense on the database with enough records but this way doesn't seem like it would be since I'm just randomly picking a number and then snagging that index out of the array of Business objects. I could be very wrong though especially if it has to create the whole array of objects every time its called. I just don't know enough about how ActiveRecord works to say one way or the other and wanted to know if someone could enlighten me.

Pollyanna posted:

There is always more, and it is always worse.

necrotic posted:

They've finally have first-class foreign key support in ActiveRecord migrations! I think the rails5 release is focused mostly on performance improvements and bug fixes over new features, with ActionCable being the big exception.

Pardot posted:

Whew, looks like Matz said no to this and it's rolled back https://bugs.ruby-lang.org/issues/12958#note-18

kayakyakr posted:

Rails 6 went official yesterday: https://weblog.rubyonrails.org/2019/8/15/Rails-6-0-final-release/

Sivart13 posted:

you don't want your job to be upgrading the massive codebase to Rails 6?

what kind of job is this that has all the rails but not wants to upgrade it

kayakyakr posted:

1) you do need a new job
2) I don't have much empathy, at least for your company, because you didn't spend any time maintaining your codebase. If you had followed along with rails versions, it wouldn't be such a massive undertaking. The longer you put it off, the more painful it will become.

Also, Rails 4 to rails 6 isn't so hard. The codebase was mature enough by Rails 4.2 that there aren't many barriers to changing over.