@Julius-Rapp I’ll see if downgrading helps us.
Hello guys, I'm trying to upgrade jsonapi-resources gem from 0.7.0 to 0.9.11 but have some difficulties as I have custom ActiveRecordOperationsProcessor which also needs to be modified.
here I do not have access to @operations & @request in 0.9.11 version as according to the docs JSONAPI::OperationsProcessor has been removed and replaced with the JSONAPI::OperationDispatcher and Processor classes per resource. The callbacks have been renamed and moved to the Processors, with the exception of the operations callback which is now on the controller. Could you hint me ?
class SidePostingActiveRecordOperationsProcessor < ActiveRecordOperationsProcessor
define_jsonapi_resources_callbacks :create_included_resource_operation
before_create_resource_operation :append_create_sideposted_to_many_resources_operations
...
def append_create_sideposted_to_many_resources_operations
return if @result.is_a?(JSONAPI::ErrorsOperationResult)
@operations.each do |operation|
resource_klass = operation.resource_klass
id_store = {}
operation.data[:to_many].each do |relationship_name, ids|
id_store[relationship_name.to_sym] = ids.dup
end
operation.data[:to_many].each do |relationship_name, ids|
relationship = resource_klass._relationships[relationship_name]
next unless relationship
sideposted_resources = sideposted_resources(relationship, id_store[relationship_name.to_sym])
next unless sideposted_resources.any?
sideposted_resources.each do |sideposted_resource|
op = create_sideposted_resource_operation(operation, relationship, sideposted_resource)
@operations << op unless operations_contain?(op)
end
end
end
end
def sideposted_resource(relationship, id)
included = @request.params[:included]
return nil unless included
type = relationship.type.to_s.dasherize
included.each_with_index do |resource_object, index|
if resource_object['type'] == type && resource_object['id'] == id
return {
index: index,
resource_object: resource_object
}
end
end
nil
end
def sideposted_resources(relationship, ids)
ids.map do |id|
sideposted_resource(relationship, id)
end.select(&:present?)
end
...
end
@joegaudet et al, sorry for being absent for the last few weeks. Luckily it has nothing to do with covid, and everything with a my lack of attention due to a tight client deadline and the gitter app not picking up new messages on my phone. I restarted the phone after the latest ios update and saw all the activity. I usually close the desktop app when on battery since it keeps the gpu engaged and makes the machine run hot, opening it when I get a notice on the phone.
I should have some more time starting in a few days and will try to catch up with questions and some JR improvements.
The perf benefits are considerable. :)
Hi guys, I'm looking for examples (or docs) on how to add functionality to a controller. basic stuff, I'm sure I'm missing it in the main docs. For example, lets say that during the creation of a model (User), we want to perform some functionality in the controller. I don't think that happens in the Resource. If it happens in the controller, I don't understand how to pass the user object back to the resource before the response is created.
Actually I'm not even sure if thats the control flow (between controllers and resources). I sort of think its not, but I don't see info on how the flow works. For example, if the controller action calls the resource for rendering the response, I don't see how to manually do that in the controller, passing my newly created user object...
the ref I've been using is: https://jsonapi-resources.com/v0.10/guide/
@scottgonzalez for every example I can come up with I know there are alternatives, so its not any specific thing. But to name a few: send off an email (yes this can be done in a call back in the model, but lets say I want to do it in the controller). Or lets say I want to update some second model when I create a primary model. Again, I know I can do these in the model, but its less about specific examples and more about a general understanding of how to perform actions in the controller, when using jsonapi-resources.
does that help?
( I looked at this section already: https://jsonapi-resources.com/v0.10/guide/resources.html#Primary-Key) but that is more for telling JR when the PK is a UUID. In my case the PK inside the app still is an integer, and only externally I'd like to use a UUID.
@keithmgould Take a look at the finders: https://jsonapi-resources.com/v0.10/guide/resources.html#Finders
That may not be fully up to date for 0.10 though.
I think this covers all the methods you would care about: https://gist.github.com/scottgonzalez/b84343cb4cf14c4639c11294c732ec67
There may be some abstractions in there that you won’t care about.
Because you’re only going to care about the find operation for IDs coming in on that resource. But then you’re also going to have to deal with any relationship data for related resources.
The responses should be easy to handle by just overriding the
id method on the resource.
But I’m not sure that would make relationship data work correctly.
I'll be caring both about finding via UUID, and also sending down those UUIDs, so I'll def look into the finder stuff you sent, but I'm still at a loss as to how to send down UUIDs (as the ID), since I can't override the
id method (as mentioned).
But I know a decent amount about how it works, so I try to at least help out here when I can since it’s a much smaller commitment.
I haven’t tried overriding the
id method before. I’d need to do quite a big of digging to see everything it would affect.
Out of curiosity, why don’t you just change that model to use the UUID as the actual primary key?
Another approach that might work out pretty well would be to create another model that just wraps the original model, but uses the UUID as the primary key.
You’d probably only need to override a few methods, like
self.find, id, id=, etc.
Yeah, I could do either of those. To answer your question though, I don't like making the UUID a primary key because it does not feel beneficial outside the world of the API. Internally (inside the app), integers are just fine, and fast, and small, and easy for a human dev to see and type when debugging. These are a lot of perks to an
int PK. And again no benefits inside the app for UUIDs. So where I've landed architecturally over the years is to have internal ints, and an external UUID, because to surface an integer PK to the world is not good for a few reasons.
I'd rather not write a wrapper, it feels like thats a lot make JR happy. But I'll go with that for now unless you find a way to make it work with overriding
id, which I'd prefer.
Also, are there examples I can find where JR sits in front of a service layer? Like lets say I have a service in the app that accepts user info from a client, does a few things, and returns something to the client. I don't want this behavior to be defined in a single model, since the behavior spans multiple models. So traditionally I create a service in the app that handles this. Can JR reference this service? What methods would need to be defined in the service? Are there examples?
I imagine its something like this now but what I have is not working:
survey = Survey.first
resource = SurveyResource.new(survey, nil)
serializer = JSONAPI::ResourceSerializer.new(SurveyResource)
serializer_set = JSONAPI::ResourceSet.new
serializer_set.populate!(serializer, nil, {})
foo = serializer.serialize_resource_set_to_hash_single(serializer_set)
render json: foo
The above is what I'm thinking about doing to address the service layer question...
Hello, I'm looking into scoping associated resources and can't make it work.
I'm trying records_for it's not being called.
class OrganizationResource < JSONAPI::Resource
has_many :accounts
# I've tried this
def records_for_accounts(relation_name, options = {})
byebug
# Not being called
Pundit.policy_scope!(options[:context][:current_user], _model.public_send(relation_name))
end
# And this
def records_for(relation_name, options = {})
byebug
# Not being called
Pundit.policy_scope!(options[:context][:current_user], _model.public_send(relation_name))
end
# This is working but it returns empty hashes on the included list
# (one hash per resource that was not allowed to be shown)
def records_for_populate(options = {})
Pundit.policy_scope!(options[:context][:current_user], _model_class.all)
end
endAny idea what's going on?
Is this deprecated or something?
The endpoint is /organizations?include=accounts
at least on
0.9.x?
it makes more sense that there isn't one for
after_destroy since it returns :no_content, but I find myself in a position to add some meta to a response after an update