Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

orderOfOperations wildcard before URL does not work #428

Open
Arch0rr opened this issue Nov 23, 2022 · 2 comments
Open

orderOfOperations wildcard before URL does not work #428

Arch0rr opened this issue Nov 23, 2022 · 2 comments

Comments

@Arch0rr
Copy link

Arch0rr commented Nov 23, 2022

Hello there, thank you for creating a great library 😀

My problem is that I'm trying to order some GETs above others. Like so:

"orderOfOperations": [
            "GET::*/Columns",
            "POST::*",
            "GET::*",
            "PUT::*",
            "DELETE::*"
        ],

But it ignores the first GET, as if it doesn't exist.
Using wildcards this way seems to work when specifying openApiOperation in other sections, however.
The */Columns response is a GET that's in quite a few folders and is to provide information to fill variables for a POST.

At the moment I'm using a Pre-request script to do the GET before the specific POST.

"operationPreRequestScripts": [
        {
            "openApiOperation": "POST::*/Query",
            "scripts": [
                ...
            ]
        }
    ]
@thim81
Copy link
Collaborator

thim81 commented Dec 2, 2022

hi @Arch0rr

The wildcard targetting can be used in combination with the option excludeForOperations, which means you target a wide range of operations but prevent excluding a number of them.

Not sure about how many operations you have, but another approach could be to build an array of openApiOperationIds.

I'm a bit puzzled about how your OAS is organized to use "GET::*/Columns".
Could you share some more context that would allow us to understand your use case better?

@Arch0rr
Copy link
Author

Arch0rr commented Dec 3, 2022

Hey @thim81
I guess my desire is to make this as streamlined and automatic as possible without needing to maintain lists or specific ids unless necessary. It shouldn't be too hard to implement the lists on my end though - just include a step before using portman to generate the portman-config file from the generated swagger file.

The */Columns use case is for doing dynamic queries between the front-end of a website and the backend server. For example Users/Columns would return the full list of the model properties (Name, Email, Permissions, etc), which columns are groupable, sortable, and visible, for the front-end table view. Then, using the Users/Query the frontend can send a 'SelectColumns', 'Conditions', 'Order', 'GroupBy', passing in a subset of the full list and using reflection, will use the passed query to the database.
eg

{
SelectColumns["Name", "Email"], // Finds the model properties with the same names and SELECTs from the database
Conditions[{"Name", 0, "Steve"}] // WHERE Name = 'Steve'
OrderBy [{"Name", 0}]  // "Name" is assumed to be sortable
}

So what I'd like to do is for each tag that has a /Columns and a /Query to use the returned /Columns results and generate a reasonable query.
By the way, it looks like I have a total of 1268 operations total, over 105 tags, so that's why I'm trying to not have to do explicit routes unless necessary.
Hope that helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants