Database selection

[barrymavin]

The "Runtime database" in the App Settings does that already. This is different, it for hosting different companies (tenants) running the same Apps against private databases.

[pauln]

Sounds great Barry - as long as we can run a single process I guess as superuser or some higher being on all the private tenants databases (if on the same VM), we can accumulate the data we need.
Regards Paul.

[hmischel@diligentsystems.com]

This is something that will be very useful.

Thanks.

Herb

[barrymavin]

After careful consideration and considering the real need for database tenancies this has now been tied in properly with a users tenancy (domain) that is specified in the "Users" workspace.

This has been implemented as follows which fits in better with the overall architecture of the Lianja Platform.

Database tenancies are based on the authenticated user. The "Database" used by an App for a particular user in a specified tenancy is postfixed with an "_" followed by the tenancy (domain) for the user specified in the "Users" workspace. For example, if the database for an App is southwind and the user has a tenacy (domain) specified of xyzco then the database used for that user will be southwind_xyzco. When the user authenticates in Desktop, Web or Mobile apps the specified database will be used rather than the default database for the App. Remember to "Deploy" the system!sysroles table and the database for that tenancy from the "Deploy" workspace.

If a user who authenticates has no tenancy specified then they belong to the "public" tenancy.

You can think of a tenancy (domain) as a "company" or "organization". This provides the ability to host a complete suite of Apps in the cloud or on a LAN with multi-company access but still maintaining security of the data across companies.

If you have hosted the Apps then you can of course consolidate information across multiple databases if you have that requirement.