Fix primary database not filter

[flaming-archer]

📝 Description

When database-resolution set manual，primary database also config some database,so to determine whether to add the fed database, it should be necessary to filter out the ones that are not in the primary database.

🔗 Related Issues

[flaming-archer]

@patduin Could you help to take a look at this? It hasn't really changed anything. Let the primaly database be used as a filter, only for its configuration, not for all.It seems very important, for example, we only select some of the primaly databasese.

[patduin]

Please add some tests. Perhaps consider jUnit and WaggeDanceIntegrationTest for this usecase.

[flaming-archer]

Please add some tests. Perhaps consider jUnit and WaggeDanceIntegrationTest for this usecase.

Sorry for late replay, I will add some tests later.

[flaming-archer]

@patduin hi,I have been very busy lately and finally have time to write. I have added a test, please help me review it.

[patduin]

Thanks! So have I! No worries thanks for adding I'll try to find some time coming week to have a look.

…

On Thu, 2 Nov 2023, 12:45 tian bao, ***@***.***> wrote: @patduin <https://github.com/patduin> hi,I have been very busy lately and finally have time to write. I have added a test, please help me review it. — Reply to this email directly, view it on GitHub <#295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAP6JGH65I76FBX2MAHSQE3YCOBT3AVCNFSM6AAAAAA5HBEGPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJQGU3TEMRTGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[flaming-archer]

@patduin Could you take a look at this. If ok, please merge it.

[patduin]

flaming-archer

Hi,

I've been busy on this as it is a bit tricky.

Thanks for writing the test that helped me understand what you were trying to fix!

Looking into this I thought the use of this panoptic class was a bit weird as we do filtering already when we add the metastore to the list (using the Allowlist).
I've made a different solution which also removes this cache which I believe is not necessary anymore.
I think it's an historical piece where we had a usecase that created databases on the metastore directly (outside of WD) and we wanted to pick those up, before we had mapping implemented.
The StaticDatabaseMappingService gets created and loaded for every request so I don't think this cache solves anything that a user can't easily solve by just reconnecting.

Why is this all tricky?
When doing static (manual) mapping things become hard when new databases are created that cause a crash, if we just crashloop WD throwing exception that the mapping should be updated. This is why I prefer the prefixes less risk of this.
I've raised a PR for this here, please have a look. And big disclaimer (sadly) I think I mentioned this before we don't run Hive3 at our company so we do not have QA setup for this branch just the unit test, please run your own QA before accepting this.
As always thanks for the contribution keen to hear your thoughts.

[patduin]

Closed in favour of: #302