#dynamic database name

1 messages · Page 1 of 1 (latest)

spice dagger
#

When creating a datasource I have several dupes of the same schema for different customers I want to be able to have a control where you select the customer (drop down or something) and the datasource changes to use a different connection. everything is the same between them other then the connection info. The only way I can figure to do this now is to clone the apps and edit the datasources but as the number of customers grows and updates to the apps occurs that could be a large and daunting task

narrow prismBOT
#

Hi! What datasource are you using?

spice dagger
#

MySQL

spice dagger
#

was able to get this to work by creating a JS function that returned the name of the schema. That function can be updated and use the store context (storeValue etc). we can then use that in our queries {{getSchemaName()}}.TableName

narrow prismBOT
#

Ok, I am glad the issue is fixed. Thank you for sharing this solution.

narrow prismBOT
#

Could you also share the piece of code you have used in your JS function for
reference for our community?

low creek
#

We have the same use-case, that we need a variable database host for MySQL. Our DB basically exists with the same tables multiple times. The best would be if we could override it per query.

narrow prismBOT
#

Are you saying that instead of separate tables, you're using separate databases?

low creek
#

Yes, because we deploy our app to multiple instances and our app has always the same tables, but the instances are hosted even in different regions.

narrow prismBOT
low creek
#

Yes, but it would be way harder for you guys to implement this. For my case just a simple "Override DB Host" input field on Queries like in Retool would completely suffice. And the sooner Appsmith has it, the sooner our company can start to pay you guys. :-)
Right now not being able to dynamically address different databases with the same queries is a complete showstopper/dealbreaker.
Example from Retool:

narrow prismBOT
#

I agree, but I believe that issue is already in our pipeline :) I don't have a
timeline for this, but if you comment your use case on that issue they will take
it into account when building the feature.