Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dmitriy "Dima" Likhten
    @dlikhten
    thanks for that!
    Adam Robertson
    @arcreative
    I'm very interested in that as well
    not just from perspective of using the netflix gem, but pluggable serializers in general
    i've created a module that uses JR internals to allow (extremely fast) output of CSV as well
    use case is "I'm viewing this list of things client-side, and now I want to export that exact list of things, sans pagination"
    obviously that would require JR to be much more abstract, and also probably not called JR, so it seems extreme
    Zach Wolfenbarger
    @zwolf

    Hi all. I'm using JR for the first time and I need to basically disable #create on a resource (they've got to be created via a non-JSONAPI endpoint, #update will be used). I'd added a method to the before_create callback that just raises a fail JSONAPI::Exceptions::Error.new("Action Not Implemented")(and a binding.pry), but the breakpoint's not hit and the errors returned are all MissingParameter, when I don't want the request to be processed at all.

    I've also tried similar ideas with the resource's corresponding Processor with no luck. Am I on the right track? Lots of ways to do this but mostly want to make sure that I'm understanding the flow properly.

    Larry Gebhardt
    @lgebhardt
    You can turn off create in the routes jsonapi_resources :contacts, except: [:create]
    Joe Gaudet
    @joegaudet
    whoa!
    That’s news to me,
    Larry Gebhardt
    @lgebhardt

    https://jsonapi-resources.com/v0.10/guide/routing.html#jsonapi-resources

    You could also override the create method on the controller

    Overriding the controller method shouldn't be needed, but it will ensure it doesn't do anything
    Zach Wolfenbarger
    @zwolf
    That was my first idea, to just render the error, but it seemed wiser to let JR raise/serialize it.
    Excluding it from the router would also work, though I'd also want to send back a useful error response. Was just curious where i was off about the callbacks...maybe it's just that before_create is post-validation, which makes those other ideas probably better in this case.
    Larry Gebhardt
    @lgebhardt
    Maybe it would be better to raise an error from the resource overriding def self.create(context).
    Zach Wolfenbarger
    @zwolf
    Oh, I tried the before_create callback in the resource, but not overriding the create method there
    Larry Gebhardt
    @lgebhardt
    That will ensure that when we do eventually add multiple operations support you don't accidentally allow creation of the resource. We'll of course need some other method to control this when that feature lands.
    I thought raising an error in before_create would also work, but your results show otherwise. One more thing to look at
    Zach Wolfenbarger
    @zwolf
    yeah, breakpoints indicate I'm not getting to the before_create method in the processor or resource, or self.create in the resource, before it returns the MissingParameter error from my {} request body. Sounds like one of the above solutions (exclude from router, override whole action) would be a better fit.
    Larry Gebhardt
    @lgebhardt
    Try sending in a valid request body. You should be able to hit the before_create callbacks, but I think the request is getting kicked out before it's even being processed
    Zach Wolfenbarger
    @zwolf
    I'll give it a try, and I'm sure I'll have more questions later, thanks!
    Adam Robertson
    @arcreative
    I always whitelist my methods in the router to avoid "mishaps"
    404 seems like the most appropriate response for this
    but thanks @lgebhardt for the tip that this might not work for multiple operations
    that actually concerns me a bit, now that I think about it... we have a lot of resources that can be edited but not created, so immutable is insufficient
    seems like there needs to be another mechanism if you're not using a gem like jsonapi-authorization
    Larry Gebhardt
    @lgebhardt
    @joegaudet I've made #1287 which I think should fix your Postgres issues. It's not quite done, but I think it should work well enough to fix your issues. Could you please test this for me?
    Joe Gaudet
    @joegaudet
    @lgebhardt test as in try it out on my branch?
    Joe Gaudet
    @joegaudet
    @lgebhardt seems to work on that branch
    Dmitriy "Dima" Likhten
    @dlikhten
    @lgebhardt been trying to migrate to 0.10.0 -- previously we had self.find and self.find_records which let me control the entirety of the query done and just return results. Now it seems that the framework really really wants to do the query optimizations (find_resource_id_tree and friends) and won't give me control anymore. Basically what would I do with a need to have a resource for something like non-activerecord objects? Is there a way to sidestep? Or do I need to override the processor now?
    Larry Gebhardt
    @lgebhardt
    @joegaudet Thanks
    Dmitriy "Dima" Likhten
    @dlikhten

    @lgebhardt thanks! Looking through it. Looks like it uses self.find and returns the resources_for response. The weirdness is that I notice that the self.find doesn't even get invoked at all allowing me to customize the query. I guess find_fragments is the first actual place where I get to override. Is that the core thing that must now be overridden to ensure that the self.find has the ability to act in a custom way?

    I think I follow what find_fragments is supposed to do. I guess I don't fully understand the relation between find_fragments and find. Is it meant to just give identities of what records would be available, after which the find is responsible for actually fetching the resources?

    Dmitriy "Dima" Likhten
    @dlikhten

    I added this

    def self.find(filters, options = {})
            raise 'foo'
          end

    to a controller that works just fine, and noticed self.find doesn't even get invoked, no exception is thrown. Just trying to understand the override points.

    Dmitriy "Dima" Likhten
    @dlikhten
    ^-- i meant to a resource. to a resource that doesn't do anything but straight up serialize an activerecord object
    Larry Gebhardt
    @lgebhardt
    @dlikhten find could/should probably be removed. It's used in a few tests, and I'm still using it in some tests in a project using JR.
    Dmitriy "Dima" Likhten
    @dlikhten
    So the only way is to override find_fragments and state which resource should be used for which object? (just making sure I understand)
    Larry Gebhardt
    @lgebhardt
    Yes, using the default processor, you must override find_fragments, find_by_key, find_by_keys, and find_to_populate_by_keys.
    Dmitriy "Dima" Likhten
    @dlikhten
    Oh I see. Thank you.
    Joe Gaudet
    @joegaudet
    @lgebhardt lmk when you publish :)
    Larry Gebhardt
    @lgebhardt
    @joegaudet I updated the PR this morning. I've twice had to restart one of the Travis builds. Seems to be the same postgres, ruby 2.5.7, rails 5.2.3 build. It runs fine the second time. I'm pretty sure it's just a test setup issue, but I'd like to figure it out before merging this into master.
    Joe Gaudet
    @joegaudet
    Makes sense
    Moses Gathuku
    @gathuku
    Hey Guys. am new to JSONAPI::Resource. Can someone help me on making a POST request. When i try sending json data with postman i get
    {
        "errors": [
            {
                "title": "Missing Parameter",
                "detail": "The required parameter, type, is missing.",
                "code": "106",
                "status": "400"
            }
        ]
    }
    Adam Robertson
    @arcreative
    You’re not structuring your request correctly. You have to send an object with a data attribute, and that data attribute needs to be another object with at least a type attribute that corresponds to the pluralized name of your resource
    Both jsonapi-resources.com and jsonapi.org have all the details you need to get started
    Moses Gathuku
    @gathuku
    Thanks @arcreative am now using
    {
        "data":{
            "type":"users",
            "attributes":{
                "name":"gathuku",
                "email":"gathuku@test.com",
                "password":"password"
            }
        }
    }
    But am getting params password is not allowed but I have actually allowed it.
    {
        "errors": [
            {
                "title": "Param not allowed",
                "detail": "password is not allowed.",
                "code": "105",
                "status": "400"
            }
        ]
    }
    Adam Robertson
    @arcreative
    Not sure, just make sure it’s an attribute on your resource. I have nine set up so you can send anything in the configuration
    Scott González
    @scottgonzalez
    @gathuku Are you providing the password as a query param or as part of the JSON body?