I have a scenario - where i want to create a dashboard where depending on the user who logs in - i want the flows to connect different DB.
User logs in (Custom Dashboard by me).
I validate the user using some backend process.
I give an option to the user which DB to connect to. (Drop Down Menu).
User selects the DB
User clicks some buttons and gets some results.
This is near about the use case.
While i understand i need to configure each DB within the configuration of SQLS node.
So for 3 DBs i will have 3 configuration nodes for SQLS connection.
My Query is - when i execute a query - is there any way - connect to 1 SQLS node and using some msg. attribute to indicate to it which Connection Configuration to use ?
Or the only option is to use switch node - and then define an option per DB and connect the option of switch Node to appropriate SQLS node with the relevant DB chosen as Connection ?
I want to avoid the switch node if possible - so that every time a new DB is needed - all that the system needs is new DB definition and no other change.
Even in that case - we should be ok. 1,2,3 remains the same. #4 each user makes his own choice... which will result in a message per user which I will process.
I am ensuring that i am maintaining the socket IDs, thereby each user gets only his data back from backend.
OK, so you retain a current db selection against each socket id. I can see this getting tricky, since a new socket is generated if a user refreshes the page for example (I think). Have you mocked up and tested this side of things to make sure your underlying concept will work ok?
On the actual question you have asked I can't see an immediate solution, but that does not mean that there is not one.
I maintain the socket ID on message (actually Dashboard does this automatically).
User selected the name of the DB and clicked ok button. This generates a message wiith both db name and that user socket ID.
So when the DB query returns something i maintain the socket ID and results are sent back to the user on the Dashboard.
If user disconnects/refreshes - then the story ends there for that socket ID. Worst case scenario - i have a message in transit (user selected DB name & clicked ok and then he refreshed before getting results ) - this message would go to DB get data - and be unable to display to relevant user since that socket id is lost. This is ok for my use case. (In case of user disconnects/refreshes - i am catching the lost event and sending the user back to start of process. )
Lets see if someone else has else it would be switch .
