The idea of a marker for file looks fine to me to handle the use case. @Vladimir is it the case for you ? I don't see by the way how a "macro" could answer this , could you give more details on what you think.
Feel free to create an enhancement request and possibly. provide a patch implementing it. Thanks for your ideas and contributions. Regards On Thursday, May 7, 2015, sebb <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > On 7 May 2015 at 01:09, Vladimir Sitnikov <[email protected]> > wrote: > >>As far as I am aware, there has been little or no demand for this on > > the user lists. > > > > How do you handle usability issues? > > Do you suggest all usability issues are out of scope of JMeter? > > No, of course not. > > But developer time is not infinite, so one must consider how useful > the change is likely to be. > > Adding bells and whistles for every single possible scenario just > results in a bloated app that is hard to maintain and use. > > > I think users are just not aware of the possibility of better life, > > thus you do not see requests > > Then there would be no enhancement requests. > > > "skip rows in CSV file" is a pure usability issue. It has manual yet > > painful WA. It has even automatic WA (e.g. some loops in jmx plan). > > However, it is just an additional pain for newcomers. > > It's only a usabiity issue if people actually need to do it. > > >>if selected, then check if the marker file > >>is present, and if so skip that many rows. > > > > I do not follow you. Initially you said existing CSV Data Set should > > not be extended: "Do you think JMeter core should handle the case -- > > no". > > Now you suggest improving it. > > I still think it is somewhat out of scope for JMeter. > > But IF it is adopted, then I don't think it makes sense to do so as a > macro function. > > >>Note that the StringFromFile function has a feature which allows the > >>use of multiple input files that can be used in sequence > > > > I do not see how it is useful in current context. > > It's an alternative approach. > > You can run a test that uses files in sequence. At the end of the > test, restart the next test starting with the first unused file. > We used this at work for long running tests (48+ hrs) that could only > use each entry in a file once. > We prepared lots of randomised files, and set each test to run with a > suitable subset. > > > When I said "5-10 input files" I meant "5-10 thread groups with each > > having its own input file". > > That is a separate issue. > > > Vladimir > -- Cordialement. Philippe Mouawad.
