Database-powered custom components

Anvil Q&A
1

What I’m trying to do:
In my application A1 I have a custom component C1 can have multiple graphical layouts.
When I use the component, in code, I call a component’s method “refresh(config_id)” that will read the configuration from DB and lay things out accordingly.

I need to use this component C1 on the other application A2.
I’d like to leverage A1’s configurations database.
So I add A1 as a dependency for A2 and use it.

What I’ve tried and what’s not working:
When I call, from A2, “refresh(config_2)” I get a “config table does not exists”.
I thought dependencies and components were somehow “isolated”, but it looks like C1 is trying to read from A2’s data tables service.

Is there a way to force it to read from its own DB?

Thanks and BR

2

I think you also need to have the config table as a shared data table in A2. Then A2 can read it.

I think this comes down to the per app permissions for data tables. A2 needs info from A1s table and so needs to have access.

3

Hm, thank you @rickhurlbatt for your suggestion.
While this might indeed work,

  1. I would not like to expose the data table to all the A2, A3, … Ax apps that are going to use the component if I can avoid that. I’d like to maintain custom component’s isolation.
  2. I’ve moved to the new editor and until now it’s not possible to add tables exposed by other Apps, isnt’it? And I am already beyond the point where I can switch back to old IDE and again to the new one.
4

  1. You could always write the config data in code like a dict in the custom component’s code and then search it locally (assuming this is just parameters or similar and can be written in code?) what is the config data stored in the table?

  2. You can switch back and fourth as much as you like. The code stays the same. I do so frequently when I need to add a shared data table

1 Like
5

1.well, app A1 (that exposes the custom component C1) is indeed a true app itself, used by a back-office to manage the various available configurations. In the end yes, config is a bunch of dicts, but they need to be stored in a DB because are maintained at runtime.
2.good to know, I didn’t even dare to try… :smiley: (but don’t you lose your custom environments, different databases, etc?)

Thanks!

6

Before I try and mess things, can someone from Anvil confirm rickhurlbatt suggestion?
In my APP now I have 3 different environments and 2 different databases, will I lose this kind of configuration if I switch back to old IDE, add the shared table from the other APP, and switch forth again?
And how do I do that on the other (non default) database too?

Thanks

7

If this is time sensitive while the UK is still asleep, you could clone your app and then make the changes in the cloned app to test it out. This would give you the confirmation you need without messing up your app.

2 Likes
8

Uh-oh you’re absolutely right! :sweat_smile: How couldn’t I think of that by myself? :smiley:

Thanks @rickhurlbatt

9

Ok, as suggested by @rickhurlbatt I’ve tried on a clone and switching back and forth doesn’t break anything apparently (I haven’t tested throughly TBH).
But I can’t find a way to add the shared table to the other, non-default, database.
If I could do that, I could survive :sweat_smile: until shared tables full support is added to the new IDE.

Any ideas to try?

Thanks and BR

10

We are also keen to learn how to do this.
We have a SysAdmin app that acts as the Tenant and main User database.
We have 2 or 3 other apps with different roles and we want to utilise the table structures from the SysAdmin app as shared and collaborative.
We will have other tables in apps 2 and 3 that will also share some tables.

11

Completely untested but I wonder if changing the database linked to the “Master” branch to the database before switching to the Classic editor would allow you to make the changes you want there. This should be possible through the Publish button at the top right. This would obviously have some unwanted side affects for the published app but you might be able to minimise the down time to a few minutes.