Database selection

[barrymavin]

We've had several developers asking how to run the same Apps against different databases depending on who the user is.

This is what "tenancies" are all about.

In order to simplify this I will be adding another field to the system!sysroles table called "database". When a user authenticates if this field in not empty then the specified database will be used rather than the default one that you have specified for the App.

This provides the ability to run the exact same Apps against different databases; e.g. one for each "company" that uses your App in the Cloud.

I will try and make this available in the final release of v1.3.

Full "tenancy" support will be added in v1.4.

[tekhong]

Hi Barry

Thanks for simplifying developing multi database application!!

In our case, some clients has multiple companies in their group and the accessible companies within the group of companies depends on the user ID or user Role. BTW, am I correct that one user role can have multiple user IDs?

Your advice is much appreciated

Thanks & Best Regards

[barrymavin]

Yes roles are whatever you want them to be then you can restrict access to apps, pages, sections and form items based on them.

As you know these can be assigned dynamically as well as statically.

[phabio]

Good job Barry,
this is very important.
This makes it even easier to do tests on data not "real" .. but on simulation on a scratch DB.

Thanks
Fabio

[pauln]

Hi Barry - we have been pondering the concept of "tenancies" for some time. Instead of having different databases can you place a Company Key against all Tables and have a single database? The advantage would be gained (for us) when we need to sweep across the database for all clients to extract a common process file.

Currently, we use a key, but our legacy APP is in the LAN world and thus segregated anyway.

[barrymavin]

Hi Paul,

No I'm sorry but that is not practical and would cause security problems in the Web and Mobile.

[pauln]

Thanks Barry.
So the job would be to "sweep" through the multiple tenancies to accumulate the process file? Or reverse engineer the procedure and have the tenancies spit the data out to a common process file?

[barrymavin]

Hi Paul,

You would just need to open the databases and accumulate a process file.

use cust1!tablename
...
use cust2!tablename
...
etc

The database name can prefix the table name without having to explicit open the database.

[pauln]

Sorry Barry to be more precise - How do you fit each tenant in that equation? i.e. tenancy1\cust1!tablename ... tenancy2\cust2!tablename

[barrymavin]

A user currently belongs to a tenancy (domain in the users workspace).

I will be adding a "database" column to the system!sysroles table.

This will be used prior to the activation of full tenancies so that a user who authenticates works with tables in the specified database.

When full tenancies are enabled then all folders (including the data directory) are private to that tenancy.

So if you look at the current directory structure On windows under the lianja\cloudserver\public\ that is the default tenancy.

If a user has a tenancy of xyz.com then there will be a directory structure that is the domain of that tenancy:

lianja\cloudserver\xyz.com\

which will include the "data" directory which in turn includes the databases for the xyz.com tenant.

This allows multiple tenants (or companies if you want to think of it like that) to be hosted on the same server or VM instance.