b2ihealthcare/snow-owl

Question about creation of new concepts in different branches

Closed this issue · 8 comments

Hi,
we are experimenting with the creation of new concepts in different branches, and we noticed an inconsistent behaviour.

So assume we have a concept A in branch B1.
If we create a new concept C with A as parent, we notice the following:

  • if we create C in B1, A is marked as a statedParent of C and a relationship of type ISA is created between C and A,
  • if we create C in a branch B2 and then merge B2 with B1, we have that A is marked as a statedParent of C but there is no ISA relationship between C and A.

The information about the ISA seems to get lost at the moment of merging the branches.

Could you please confirm if this is the expected behaviour or a bug?

Thanks

cmark commented

Hi @cristinacivili-work,

We will investigate this, but this should not happen and if it does then that is a bug.
Could you please tell me the exact branches you have used? Was B1 the MAIN branch?
Is there any relationship between B1 and B2 branches?
We have several automated test cases that ensure that branch merging makes all content from the B1 branch visible to the B2 branch.
Usually, there is a parent-child relationship between the two branches, like B1 is the MAIN branch and B2 is the MAIN/child branch.

Cheers,
Mark

Good morning Mark,
thank you for your reply.
I can confirm that the second branch is a direct child of the first one and we are merging the child branch into the father. The structure is as follow:

  • Father: MAIN/SNOMEDCT_UK/B1
  • Child: MAIN/SNOMEDCT_UK/B1/B2

I forgot to mention that we are also deleting the child branch after the merge, but i don't expect this to be an issue if the merge has worked properly.

Thanks,
Cristina

cmark commented

Hi @cristinacivili-work,

Sorry for my late reply.
I'll create a simple test case to verify that deleting the child branch after merging it into the parent in fact does not cause any issues.

Get back to you soon.
Cheers,
Mark

cmark commented

Hi @cristinacivili-work,

It looks like the described functionality works as expected (see test cases above), even if we delete the child branch after merging it into the parent. Searching and retrieving content works just fine.
Another thing that comes to my mind is an Elasticsearch cluster issue, where a search does not return the desired results due to inconsistencies in the indexes and that could be related to Elasticsearch cluster misconfiguration.

This is our Elasticsearch configuration when running Snow Owl with an external single node ES cluster:
https://github.com/b2ihealthcare/snow-owl/blob/7.x/docker/docker-compose.yml#L8-L18
Could you please try your use case with the single-node configuration and verify that it works fine? Thanks!

Regards,
Mark

cmark commented

Hi @cristinacivili-work,

I think we have found the issue and working on the fix.
May I ask, did you perform a rebase (parent -> child merge) before merging the content from the child to the parent?
If yes, then there is a bug that makes the content before the sync point invisible, therefore when merging the child into the parent, only the changes made after the synchronization point get actually merged.
The fix will be available in the upcoming 7.8.0 release.

Cheers,
Mark

Thank you for your help Mark,
it was some time ago and I have been unable to reproduce the issue recently, but it is possible that we performed a rebase.
If we spot the same issue again I will make sure to track if a rebase is also involved.

May I ask you to take a look at this other issue that we are experiencing #578?

Thanks again,

Cristina

cmark commented

Hi @cristinacivili-work,

This issue is now potentially fixed by PR #621.

Regarding the classification issue, not sure if we will have time to look at it before the upcoming 7.8.0 release, but we will definitely do so in the next 7.9.0 release.

Cheers,
Mark

cmark commented

Hi @cristinacivili-work,

I'm closing the ticket now, as we have released 7.8.0 with the fix.
Also, I'd like to raise your attention of this performance issue #626.

Regards,
Mark