The Google App Engine works great in terms of a multitasking application using namespaces. However, when you use Cloud SQL as a data storage mechanism, you begin to run into problems. In particular, how one could connect different databases to each namespace. Currently, the database used by the entire application is set in the instance configuration, so it is pretty heavily encoded in the deployment from what I can assume.
I understand that the exact architecture underlying the multitasking application is different for business needs (or at least should be, if it is useful for scaling), however, I would be pleased with some generalized solutions specifically designed to create a multi-storey application with Google Cloud SQL
I am trying to avoid creating a column with multiple tenants (if someone cannot explain why the very nature of this sql cloud denies the need for me to worry about everything in one monolithic database). The ideal imho scenario would be to have one application using the api namespace attached to different databases (they all use the same scheme) and some kind of list data synchronization mechanism for all database tenants.
Other ideas we had:
- Each tenant has his own application and, therefore, a hard-coded database .. with the problem of synchronizing list data (publisher / broadcast, proxy?).
- Each tenant has its own version and therefore a hard-coded database. Use the data store for the list data.
- One application, one database, namespace-based prefix table names (but we cannot figure out how to make this work with JPA dynamically)
We are also not completely negative about using another compatible sql cloud data provider.
Finally, you may ask why use SQL at all. The only reason is the ability of more than one application to read and write from it at the same time, because the data warehouse does not allow it.