Yes, I'm starting to learn this. When I say distributed, I mean I'm linking applications with rabbitmq and ruby amqp. I then pass a message that's serialized in json. The issue is normal integer id's between apps will clash, so I was going to use uuid as the id instead.I'm guessing you are saying make the uuid another field, and just update the object. So the two applications would maintain their own id's, but match uuid's? Is there not a method of doing this that already works. I know I'm not the first to pass objects around.
On Wed, Jun 15, 2011 at 12:05 PM, Peter De Berdt <[email protected]>wrote: > On 15 Jun 2011, at 17:22, Colin Law wrote: > > This whole method runs into a lot of issues. What about has_many objects, > > they won't update with new id either. Is there not a method to have rails > > add or update based on id in a new object? Is this not how I should be > > working with distributed objects? > > > Have you tried using a before_create filter to force the id to the > appropriate value? I have not done this myself but I seem to remember > the technique being suggested. > > Colin > > > On Wed, Jun 15, 2011 at 10:47 AM, Justin Stanczak <[email protected]> > > wrote: > > > To narrow down the issue I'm having, I can update an object that exists. > > Like so: > > stu = Student.find('8edcfd63-801c-4ad3-b811-a6bdc440810e') > > #### This will update the obj, but leave the id unchanged > > stu.update_attributes!(JSON.parse(json_string)) > > But this will not work: > > ### Will not find this id > > stu = Student.find('c6a4673e-90bd-4793-a62f-2e2fbdb857f6') > > stu = Student.new > > ### ID will be nil after this update > > stu.update_attributes!(JSON.parse(json_string)) > > ### a forced save false will create a new id, not the one assigned by json > > > I would think I'm just missing something simple, or how would a > > distributed system work in Rails/Ruby? > > > Tinkering with what Rails consideres a "do-not-touch" value always gets you > into trouble. Mass assignment for ids is out of the question, as far as I > know so is setting the field individually through self.id= It's with good > reason too, the chance you'll screw up referential integrity is too big. > > There probably is some obscure way to set the id, but instead I would just > slap myself on the head and wonder: why the hell did I ever come up with the > idea of making that field the primary key instead of letting Rails handle it > and store that external JSON ID in some field I can actually change :-) > > BTW, what do you mean with a "distributed system"? If you're using a > distributed database, the database will take care of the ID assignment. My > impression is that you have an external application that you access through > a JSON API and you want to search the ID field from the other application in > your Rails application. That would be so easy if you just let Rails handle > it's primary key thing (creating its own autoincrement ids), make a new > field called "my_fancy_dandy_external_api_id", index it and store the value > of the external app there. You can then fiddle with it all you want, Rails > won't care. > > > Best regards > > > Peter De Berdt > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
