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

Avoid multiple BT instances initialization #290

Closed
okainov opened this issue Apr 4, 2018 · 3 comments
Closed

Avoid multiple BT instances initialization #290

okainov opened this issue Apr 4, 2018 · 3 comments

Comments

@okainov
Copy link
Contributor

@okainov okainov commented Apr 4, 2018

Description of problem

Connection to BT is being established every time when object-child of IssueTrackerType is being created. For JIRA specifically, it means that every time new jira.JIRA object is being created and new connection is being established. Taking into account possibility of multiple requests it makes sense to extract establishing the connection to some kind of singleton or classmethod.

Actually, from the first sight I would say that all methods from IssueTrackerType should be static, so calls should look like:
JIRA.add_testcase_to_issue(case, bug)

Component (web, API, etc)

core

Additional info

@okainov
Copy link
Contributor Author

@okainov okainov commented Apr 27, 2018

Simple partial solution which will already help if someone first gets IssueTracker object and than executes multiple requirests to it is just to declare rpc as Jira class variable and in init you add check if JIRA.rpc is not None

@atodorov
Copy link
Member

@atodorov atodorov commented Jan 7, 2019

Simple partial solution which will already help if someone first gets IssueTracker object and than executes multiple requirests to it is just to declare rpc as Jira class variable and in init you add check if JIRA.rpc is not None

For the record you will have to keep a reference to the tracker parameter b/c there could be multiple JIRA instances defined in the database. Making a rpc attribute class based will always point to the first instance that happens to be used by the engineer reporting a bug. The next person that wants to report a bug may be working on a completely different product.

@okainov
Copy link
Contributor Author

@okainov okainov commented Jan 8, 2019

I believe, multiple JIRA instances is kind of exceptional case. We implemented this WA in our fork and pretty happy with it. But of course there is always space for improvements

@atodorov atodorov added this to the bug-tracker integration milestone Jul 30, 2019
atodorov added a commit that referenced this issue Sep 2, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 2, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 3, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 4, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 13, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 15, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
atodorov added a commit that referenced this issue Sep 18, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
@atodorov atodorov closed this in 8b75318 Sep 19, 2019
SvetlomirBalevski added a commit to SvetlomirBalevski/Kiwi that referenced this issue Sep 24, 2019
in this way we create object to connect to the remote end only
once, which should improve speed of work when working often with
bugs directly from Kiwi TCMS. This also makes it possible to
still have multiple IT integrations in the same instance b/c they
will have unique base URLs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants