Dear Ranorex,
Is there a recommended limit that exists to the number of repository items that can be held within a repository? Can a repository that is too large cause the automation to run slower?
Thanks,
Martin
number of items in a repository
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: number of items in a repository
Hi,
Regards,
Peter
Ranorex Team
Normally there shouldn't be a limitation. Is there a specific reason why you ask? Did you reach a limit in your repo?martinsw wrote:Is there a recommended limit that exists to the number of repository items that can be held within a repository? Can a repository that is too large cause the automation to run slower?
Regards,
Peter
Ranorex Team
Re: number of items in a repository
Hi Peter,
The nature of my application under tests means that I am frequently faced with two options when creating repository items. I can create a more generic ranorexpath to the element and then specify the particular attributes within the recording. Alternatively, I can include the attributes within the Ranorex path itself.
I prefer the latter method because it means that i don't have to rely on arbitrary delays as much within my recording. I don't like the delays because it's very hard to work out how long the delay should be (too short and the automation may fail in times when the application is running slower than normal; too long and the automation becomes innefficient and too slow to execute).
However, the latter method also results in me having to create more repository items than I would have to do if I was using the first method.
I just want to make sure that following the second method won't lead to performance degredation further down the line due to me having too many items within my repository. Can you confirm please?
Just to clarify, I have not received any messages saying that i've reached a limit in my repository. I am asking the question so that I can work out the best way of designing my automation.
Thanks.
The nature of my application under tests means that I am frequently faced with two options when creating repository items. I can create a more generic ranorexpath to the element and then specify the particular attributes within the recording. Alternatively, I can include the attributes within the Ranorex path itself.
I prefer the latter method because it means that i don't have to rely on arbitrary delays as much within my recording. I don't like the delays because it's very hard to work out how long the delay should be (too short and the automation may fail in times when the application is running slower than normal; too long and the automation becomes innefficient and too slow to execute).
However, the latter method also results in me having to create more repository items than I would have to do if I was using the first method.
I just want to make sure that following the second method won't lead to performance degredation further down the line due to me having too many items within my repository. Can you confirm please?
Just to clarify, I have not received any messages saying that i've reached a limit in my repository. I am asking the question so that I can work out the best way of designing my automation.
Thanks.
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: number of items in a repository
Hi,
Maybe the following blog will help you to design your test project.
Regards,
Markus
Ranorex Support Team
It normally won't lead to performance reduction as it is the fastest method, but we do not suggest to use a single huge repository, to split it up into more smaller ones is a better, the recommended way .I just want to make sure that following the second method won't lead to performance degredation further down the line due to me having too many items within my repository. Can you confirm please?
Maybe the following blog will help you to design your test project.
Regards,
Markus
Ranorex Support Team
Re: number of items in a repository
Hi Markus,
Thanks for the link, I will check it out.
Thanks for the link, I will check it out.