I'm writing a Gatling simulation, and I want to verify both that a certain element exists, and that the content of one of its attributes starts with a certain substring. E.g.:
val scn: ScenarioBuilder = scenario("BasicSimulation")
.exec(http("request_1")
.get("/path/to/resource")
.check(
status.is(200),
css("form#name", "action").ofType[String].startsWith(BASE_URL).saveAs("next_url")))
Now, when I add the startsWith above, the compiler reports an error that says startsWith is not a member of io.gatling.http.check.body.HttpBodyCssCheckBuilder[String]. If I leave the startsWith out, then everything works just fine. I know that the expected form element is there, but I cant confirm that its #action attribute starts with the correct base.
How can I confirm that the attribute start with a certain substring?
Refer this https://gatling.io/docs/2.3/general/scenario/
I have copied the below from there but it is a session function and will work like below :-
doIf(session => session("myKey").as[String].startsWith("admin")) { // executed if the session value stored in "myKey" starts with "admin" exec(http("if true").get("..."))}
I just had the same problem. I guess one option is to use a validator, but I'm not sure how if you can declare one on the fly to validate against your BASE_URL (the documentation doesn't really give any examples). You can use transform and is.
Could look like this:
css("form#name", "action").transform(_.startsWith(BASE_URL)).is(true)
If you also want to include the saveAs call in one go you could probably also do something like this:
css("form#name", "action").transform(_.substring(0, BASE_URL.length)).is(BASE_URL).saveAs
But that's harder to read. Also I'm not sure what happens when substring throws an exception (like IndexOutOfBounds).
I am using the MultiLevelJsonExtractor forked on Git by kotvisbj, When I put a Path that contains an array (body.header.items[*] or body.header.items) into the JsonPaths parameter string, I get a "Error: Path returned multiple tokens". Is there a way to extract the paths in code so I can get an array like when using the Root? I tried to explain this the best way I could, I don't have excellent c# skills, it's been a few years.
I think it would be best to ask the owner of the branch to see if he can advise you. I assume that his code expects a single token only and not an array of tokens.
You can probably achieve what you need by using code similar to this: U-SQL - Extract data from json-array
I am trying to find entities (Tags) in the database via their Name property, where it is important to ignore the case (When database is searched and the Database contains a Tag with the name Database, that one should be returned). Right now, my code looks like this:
public IEnumerable<db.Tag> FindByNames(IEnumerable<string> tagNames)
{
return this.DatabaseContext.Tags
.Where(tag => tagNames.Contains(tag.Name));
}
Obviously, this one is case sensitive. I have tried to provide StringComparer.OrdinalIgnoreCase as comparer to the Contains method, but got a warning during execution that the expression could not be translated and would be executed in code rather than in the database (I don't remember the exact message, I will edit as soon as I am back on my development machine). I can live with that if I have to, but it would be nice to know how to let the database do the work in this case. Is it possible?
No change should be necessary. SQLite's "LIKE" is already case-insensitive.
The default behavior of the LIKE operator is to ignore case for ASCII characters.
(cref https://www.sqlite.org/pragma.html#pragma_case_sensitive_like and Case sensitive and insensitive like in SQLite)
Of course, you can always use .FromSql() to get the exact query you want. Example:
context.Tags.FromSql("SELECT * FROM tags WHERE name LIKE '%{0}%'", tagName)
I have a REST api written in Symfony2 with an API call to upload a file.
This file can't be more than 40MB and must respect some format.
I would like to know how I can create a fake UploadedFile
according to Symfony2 documentation , it seems possible to precise the mime type, size and name , and even a mysterious "test" parameters (which i first thought was to be put as true when one want to tell Symfony it's a fake one) but it does not work (it wants a valid file path)
So how does people do, as in my case I can't put a 50mo file in my repository just for the sake of one functional test.
I have a Java component which scans through a set of folders (input/processing/output) and returns the list of files in JSON format.
The REST URL for the same is:
GET http://<baseurl>/files/<foldername>
Now, I need to perform certain actions on each of the files, like validate, process, delete, etc. I'm not sure of the best way to design the REST URLs for these actions.
Since its a direct file manipulation, I don't have any unique identifier for the files, except their paths. So I'm not sure if the following is a good URL:
POST http://<baseurl>/file/validate?path=<filepath>
Edit: I would have ideally liked to use something like /file/fileId/validate. But the only unique id for files is its path, and I don't think I can use that as part of the URL itself.
And finally, I'm not sure which HTTP verb to use for such custom actions like validate.
Thanks in advance!
Regards,
Anand
When you implement a route like http:///file/validate?path you encode the action in your resource that's not a desired effect when modelling a resource service.
You could do the following for read operations
GET http://api.example.com/files will return all files as URL reference such as
http://api.example.com/files/path/to/first
http://api.example.com/files/path/to/second
...
GET http://api.example.com/files/path/to/first will return validation results for the file (I'm using JSON for readability)
{
name : first,
valid : true
}
That was the simple read only part. Now to the write operations:
DELETE http://api.example.com/files/path/to/first will of course delete the file
Modelling the file processing is the hard part. But you could model that as top level resource. So that:
POST http://api.example.com/FileOperation?operation=somethingweird will create a virtual file processing resource and execute the operation given by the URL parameter 'operation'. Modelling these file operations as resources gives you the possibility to perform the operations asynchronous and return a result that gives additional information about the process of the operation and so on.
You can take a look at Amazon S3 REST API for additional examples and inspiration on how to model resources. I can highly recommend to read RESTful Web Services
Now, I need to perform certain actions on each of the files, like validate, process, delete, etc. I'm not sure of the best way to design the REST URLs for these actions. Since its a direct file manipulation, I don't have any unique identified for the files, except their paths. So I'm not sure if the following is a good URL: POST http:///file/validate?path=
It's not. /file/validate doesn't describe a resource, it describes an action. That means it is functional, not RESTful.
Edit: I would have ideally liked to use something like /file/fileId/validate. But the only unique id for files is its path, and I don't think I can use that as part of the URL itself.
Oh yes you can! And you should do exactly that. Except for that final validate part; that is not a resource in any way, and so should not be part of the path. Instead, clients should POST a message to the file resource asking it to validate itself. Luckily, POST allows you to send a message to the file as well as receive one back; it's ideal for this sort of thing (unless there's an existing verb to use instead, whether in standard HTTP or one of the extensions such as WebDAV).
And finally, I'm not sure which HTTP verb to use for such custom actions like validate.
POST, with the action to perform determined by the content of the message that was POSTed to the resource. Custom “do something non-standard” actions are always mapped to POST when they can't be mapped to GET, PUT or DELETE. (Alas, a clever POST is not hugely discoverable and so causes problems for the HATEOAS principle, but that's still better than violating basic REST principles.)
REST requires a uniform interface, which in HTTP means limiting yourself to GET, PUT, POST, DELETE, HEAD, etc.
One way you can check on each file's validity in a RESTful way is to think of the validity check not as an action to perform on the file, but as a resource in its own right:
GET /file/{file-id}/validity
This could return a simple True/False, or perhaps a list of the specific constraint violations. The file-id could be a file name, an integer file number, a URL-encoded path, or perhaps an unencoded path like:
GET /file/bob/dir1/dir2/somefile/validity
Another approach would be to ask for a list of the invalid files:
GET /file/invalid
And still another would be to prevent invalid files from being added to your service in the first place, ie, when your service processes a PUT request with bad data:
PUT /file/{file-id}
it rejects it with an HTTP 400 (Bad Request). The body of the 400 response could contain information on the specific error.
Update: To delete a file you would of course use the standard HTTP REST verb:
DELETE /file/{file-id}
To 'process' a file, does this create a new file (resource) from one that was uploaded? For example Flickr creates several different image files from each one you upload, each with a different size. In this case you could PUT an input file and then trigger the processing by GET-ing the corresponding output file:
PUT /file/input/{file-id}
GET /file/output/{file-id}
If the processing isn't near-instantaneous, you could generate the output files asynchronously: every time a new input file is PUT into the web service, the web service starts up an asynchronous activity that eventually results in the output file being created.