I have a JSR223 Sampler where i am getting two values and based on that two values, i have to make nested Switch controller ,
vars.put('counts',new
groovy.json.JsonSlurper().parse(prev.getResponseData()).options.size() as
String)
if (Count==1) {
vars.put('Opt', 'Single')
} else {
vars.put('Opt', 'double')
}
def size = com.jayway.jsonpath.JsonPath.read(prev.getResponseDataAsString(),
'$.options_available')
if (size == []) {
vars.put('size', 'NonConfigurable')
} else {
vars.put('size', 'Configurable')
}
if count ==1 , then control should be Configurable -> Single Controller
if count==2 , then control should be Configurable -> Double Controller
How to implement the above case with nested Switch controller in Jmeter ? Help is useful.
Sounds like a single Switch Controller should be enough, just use ${Opt}-${size} as "Switch Value" and create the following switch branches:
Single-Configurable
Single-NonConfigurable
double-Configurable
double-NonConfigurable
Also be aware that if certain actions assume shared test elements which are applicable for > 1 switch branch you can consider using Module Controller to avoid code duplication.
Related
I have a page with a grid view and the possibility to filter on elements. If i ex. do the following the test will fail as the grid view hasn´t updated when filter is applied.
cy.get('[data-cy="elements"]').each((element)=> {
expect(element.text()).to.equal('something)
});
Currently i have a custom command that wait for a loading indicator to disappear but i would love to see if there is a better solution like you can do when you have a single element: cy.get('[data-cy="elements"]').should('have.text, 'something');
I´ve seen that you could do something like this but then i have to check each element using eq which isn´t that beautiful:
cy.get('[data-cy="elements"]').should((elements)=> {
expect(elements.eq(0).text()).to.equal('something');
expect(elements.eq(1).text()).to.equal('something');
expect(elements.eq(2).text()).to.equal('something');
}}
use this:
cy.get('[data-cy="elements"]').should((elements)=> {
for(var i = 0; i < elements.length; i++) {
expect(elements.eq(i).text()).to.equal('something');
}
}
each is not suitable here because as the docu ( https://docs.cypress.io/api/commands/each.html#Assertions ) also states, it is not repeatable. So it will fail on the first failing assertion.
So use should with a callback function to take advantage of the repeat feature of cypress.
Are there any best practices or ReQL features that that help with composing complex ReQL queries?
In order to illustrate this, imagine a fruits table. Each document has the following structure.
{
"id": 123,
"name": "name",
"colour": "colour",
"weight": 5
}
If we wanted to retrieve all green fruits, we might use the following query.
r
.db('db')
.table('fruits')
.filter({colour: 'green'})
However, in more complex cases, we might wish to use a variety of complex command combinations. In such cases, bespoke queries could be written for each case, but this could be difficult to maintain and could violate the Don't Repeat Yourself (DRY) principle. Instead, we might wish to write bespoke queries which could chain custom commands, thus allowing complex queries to be composed in a modular fashion. This might take the following form.
r
.db('db')
.table('fruits')
.custom(component)
The component could be a function which accepts the last entity in the command chain as its argument and returns something, as follows.
function component(chain)
{
return chain
.filter({colour: 'green'});
};
This is not so much a feature proposal as an illustration of the problem of complex queries, although such a feature does seem intuitively useful.
Personally, my own efforts in resolving this problem have involved the creation of a compose utility function. It takes an array of functions as its main argument. Each function is called, passed a part of the query chain, and is expected to return an amended version of the query chain. Once the iteration is complete, a composition of the query components is returned. This can be viewed below.
function compose(queries, parameters)
{
if (queries.length > 1)
{
let composition = queries[0](parameters);
for (let index = 1; index < queries.length; index++)
{
let query = queries[index];
composition = query(composition, parameters);
};
return composition;
}
else
{
throw 'Must be two or more queries.';
};
};
function startQuery()
{
return RethinkDB;
};
function filterQuery1(query)
{
return query.filter({name: 'Grape'});
};
function filterQuery2(query)
{
return query.filter({colour: 'Green'});
};
function filterQuery3(query)
{
return query.orderBy(RethinkDB.desc('created'));
};
let composition = compose([startQuery, filterQuery1, filterQuery2, filterQuery3]);
composition.run(connection);
It would be great to know whether something like this exists, whether there are best practises to handle such cases, or whether this is an area where ReQL could benefit from improvements.
In RethinkDB doc, they state it clearly: All ReQL queries are chainable
Queries are constructed by making function calls in the programming
language you already know. You don’t have to concatenate strings or
construct specialized JSON objects to query the database. All ReQL
queries are chainable. You begin with a table and incrementally chain
transformers to the end of the query using the . operator
You do not have to compose another thing which just implicit your code, which gets it more difficult to read and be unnecessary eventually.
The simple way is assign the rethinkdb query and filter into the variables, anytime you need to add more complex logic, add directly to these variables, then run() it when your query is completed
Supposing I have to search a list of products with different filter inputs and getting pagination. The following code is exposed in javascript (This is simple code for illustration only)
let sorterDirection = 'asc';
let sorterColumnName = 'created_date';
var buildFilter = r.row('app_id').eq(appId).and(r.row('status').eq('public'))
// if there is no condition to start up, you could use r.expr(true)
// append every filter into the buildFilter var if they are positive
if (escapedKeyword != "") {
buildFilter = buildFilter.and(r.row('name').default('').downcase().match(escapedKeyword))
}
// you may have different filter to add, do the same to append them into buildFilter.
// start to make query
let query = r.table('yourTableName').filter(buildFilter);
query.orderBy(r[sorterDirection](sorterColumnName))
.slice(pageIndex * pageSize, (pageIndex * pageSize) + pageSize).run();
I perform a variety of actions on my model, eg.
User::destroy(Input::get('data'));
I need to test whether the above operation was sucessful or not, how would I go about doing it?
I've tried:
$deleted = User::destroy(Input::get('data'));
if (is_null($deleted) ) {
App::abort(404);
}
But to no avail.
What is recommended practice here?
If you take a look at the Illuminate\Database\Eloquent\Models destroy() method you can see that it returns the number of records deleted.
So the most elegant way to go through it would probably be:
$deleted = User::destroy(Input::get('data'));
if ( $deleted === 0 ) {
App::abort(404);
}
However if you don't care about strict comparison you could just go with:
if( ! User::destroy(Input::get('data') )
{
App::abort(404);
}
That works because 0 evaluates to false when not comparing strictly. That's also what the comments on the method say (1058-1060):
We'll initialize a count here so we will return the total number of deletes
for the operation. The developers can then check this number as a boolean
type value or get this total count of records deleted for logging, etc.
I would suggest you stick with strong comparison because the return type is just clearer, but you're free to choose whatever you want.
You should be able to just do
if(User::destroy(Input::get('data')))
{
}
This should return true or false if the user has been deleted.
Hope that helps.
I would like to benchmark single TypoScript object generation to control the performance, is it possible, probably, with some stdWrap methods ?
Example of TS objects, which I would like to benchmark :
Test 1
page.10 = RECORDS
page.10 {
tables = pages
source = 1
dontCheckPid = 1
conf.pages = TEXT
conf.pages.field = title
}
Test 2
page.20 = CONTENT
page.20 {
table = tt_content
select {
pidInList = 0
recursive = 99
where = uid = 1
}
}
I need each object generation time and quantity of fired queries.
I guess it could be done via Extension. I guess there is a possibility to hook in (or xclass) the Database Layer (like DBAL does). In your extension you could then just test the different TypoScript setups via $this->cObj->cObjGetSingle($this->conf['test1'],$this->conf['test1.'],'test1');
Perhaps have a look at t3lib_timeTrack, may be it is enough what is tracked there. But AFAIK everything which is tracked is available via Admin-Panel (check all checkboxes).
I want to do something like
from table1
where col5="abcd"
select col1
I did like
query_ = From g In DomainService.GetGEsQuery Select New GE With {.Desc = g.codDesc}
"This cause a runtime error, i tried various combinations but failed"
please help.
I'm assuming your trying to do this on the client side. If so you could do something like this
DomainService.Load(DomainService.GetGEsQuery().Where(g => g.codDesc == "something"), lo =>
{
if (lo.HasError == false)
{
List<string> temp = lo.Entities.Select(a => a.Name).ToList();
}
}, null);
you could also do this in the server side (which i would personally prefer) like this
public IQueryable<string> GetGEStringList(string something)
{
return this.ObjectContext.GE.Where(g => g.codDesc == something).Select(a => a.Name);
}
Hope this helps
DomainService.GetGEsQuery() returns an IQueryable, that is only useful in a subsequent asynchronous load. Your are missing the () on the method call, but that is only the first problem.
You can apply filter operations to the query returned using Where etc, but it still needs to be passed to the Load method of your domain context (called DomainService in your example).
The example Jack7 has posted shows an anonymous callback from the load method which then accesses the results inside the load object lo and extracts just the required field with another query. Note that you can filter the query in RIA services, but not change the basic return type (i.e. you cannot filter out unwanted columns on the client-side).
Jack7's second suggestion to implement a specific method server-side, returning just the data you want, is your best option.