[RubyAMF] Using client generated ID's instead of ActiveRecord ID's

[Chris Brown]

I've setup rails and AMF to use uuid's everything works fine as long
as Rails is generating the uuid's. But what I want is for my clients
to generate the uuid's. The problem is that when I do a save passing
on a new object, because it has its ID property set, AMF obviously
assumes that it's an existing record and generate an ActiveRecord as
such. When I call save no error is thrown and looking at the logs
shows me that it's attempted to do an update instead of an insert.

For what I want to work AMF will need to always check whether the id
provided already exists, if so it can use the existing record, if not
it will create a new one.

Can anyone tell me if AMF supports client generated ID's or can point
me to the place in the code where I might be able to patch this.

Cheers,

Chris

--
You received this message because you are subscribed to the Google Groups "rubyamf" group.
To post to this group, send email to rub...@googlegroups.com.
To unsubscribe from this group, send email to rubyamf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyamf?hl=en.

[fosrias]

Chris. There is a patch in the works here:

http://code.google.com/p/rubyamf/issues/detail?id=125

If you look at the attached files you will find where the id is set
and why this happens. I have thought about your issue with respect to
custom primary keys and even with the new patch, that is likely to
remain an issue based on how rubyamf deserializes an ActiveRecord and
how it decides if it is a new record or not (note how composite
primary keys are handled in the patch vo_helper.rb).

I do not think you can get away from this without adding lookup
overhead to rubyamf for all the standard users and thus are not likely
to get a patch that fixes this. I would use a before save callback in
your models that you set the id on. Something like this.

self.instance_variable_set('@new_record', true) if !self.class.exists?
(self.id)

Hope that keeps you going.

[fosrias]

Upon further thought, it is possible that rubyamf could be patched to
handle this, but it would require using custom primary keys and then
the patch would be to do a look up if using a custom primary key vs. a
composite primary key. This would keep the overhead down and I solve
the problem.

Will talk to victor about this.

[fosrias]

Chris:

Attached an updated file that fixes this and I suspect is on its way
to trunk this weekend. It does however require using a custom primary
key to accomplish setting your own ids. Otherwise, the callback
suggestion above will work, I think. Check here:

http://code.google.com/p/rubyamf/issues/detail?id=125#c5

Mark

[fosrias]

If that does not do it, you could create patch after the
aforementioned patch is applied that defines a
mapping :use_generated_ids (or something) in rubyamf_config.rb and
then modify the aforementioned patch on line 94 to be:

map = ClassMappings.get_vo_mapping_for_ruby_class(obj.class.to_s)
if primary_key != 'id' || map[:use_generated_ids]

Since this is only called once per deserialization, the performance
hit would be negligible. However, I am not sure that ActiveRecord will
allow you to set your own id if it is not a custom primary key. You
would have to test this and see when id is set and the record is being
saved as a new record.

Mark