Best practice: SaaS with SmartGWT

[Isomorphic]

As it happens, it's currently implemented as an entirely dynamic lookup. However, how could it matter? Are you saying different customers have different translations for the same string, even within the same locale? That seems nonsensical.

[Blama]

Hi Isomorphic,

agreed. This only affects DataSources where something can be different depending on the customer.
For these I can either suffix them and also modify all fields linking to them. But this "linking to them" is transitive -> most likely all DS need to be dynamic, then.
Or I turn of pooling for generated DataSources off. Clear so far.

Another question w.r.t this: Is the customized fmt-tag DataSource localization result cached per DataSource, meaning that I have to suffix all DataSources if I'm using that feature with different results per customer once 12.1 becomes a "p" version?

Best regards
Blama

[Isomorphic]

Not following this. If you have different tableNames per customer you can go ahead and dynamically generated DataSources with customer-specific suffixing as previously discussed. This still does not imply turning off pooling. It also still does not imply that *every* DataSource must be suffixed, only those where you choose to have different tables per customer.

[Blama]

Hi Isomorphic,

I already do have customerId columns. The problem I see is the following:
Depending on a setting that is per customer, I change the tableName of a DataSource.
Now I if have a dynamic DataSource with ID "myDS_cust001" I can set the tableName as needed and everything is OK, even if pooled.
If I only have a dynamic DataSource with ID "myDS" and I set the tableName like it is correct in that case (I can get the customer and the correct setting via the httpRequest's domain name), whatever customer 1st requests the DS will manifest it's configuration in the pool -> problem.
But if I disable the pool and run the XML modification of RegisterDS every time, it will always be correct.

I'm pretty sure the correct/suggested solution is to make all DS dynamic and suffix them, but I'd the other way is faster to develop and perfectly fine IMHO, if it does not have performance implications.

Best regards
Blama

[Isomorphic]

We’re not sure how 2) would actually work to create per-customer data, unless you introduce customerId columns. And if you did that, there would again be no reason to turn off pooling.

[Blama]

Hi Isomorphic,

Suffixing DataSources is a reasonable multi-home strategy we've used before. The alternative is of course having a customerId column. The latter makes it easier to do cross-customer reporting among other things. The two strategies can be mixed.

Thanks. It's always good to know not to be the 1st one with a specific setup.
I do also have a customerId column.

Suffixing DataSources does not imply that DataSource pooling needs to be turned off, and we would not recommend doing so.

Sorry, misunderstanding here.
I meant in order to solve the problem I could do either:

1. Make all DS Dynamic and with suffix OR
2. Leave all DS as they are and turn off pooling

Does 1) Need more changes than rewriting ID and also foreignKey and includeFrom?
Would 2) solve my issue (Some DataSources that already Dynamic would indeed be different per customer)? Is there some performance impact to expect?

Thank you & Best regards
Blama

[Isomorphic]

This is a bit of an odd post.. your first question you’ve asked in another thread already, it will be answered there. The other two sound like vague unease as to whether features will work as documented. They will or we’ll fix them.

Suffixing DataSources is a reasonable multi-home strategy we’ve used before. The alternative is of course having a customerId column. The latter makes it easier to do cross-customer reporting among other things. The two strategies can be mixed.

Suffixing DataSources does not imply that DataSource pooling needs to be turned off, and we would not recommend doing so.

[Blama]

Hi Isomorphic,

can you share your best practice / advice on this one?
We are making a SaaS based on SmartGWT. Right now, this means an (easy, because automated) build of ~30x 50 MB test and customers war files (takes 15min, only one run of gwtc needed) and upload of it (1,5 GB).
This works, but is a tedious and annoying task that does not scale.


So the idea is to move all the customers to 1 WAR. This means the following tasks:

• All customer specific code must come from the DB
• All customer specific "files" (e.g. HTML mail templates) must come from the DB
• All customer specific field names must come from the DB
• Application must use DB access that can access all data (before I used separate schemas), WHERE clause set in SQLDataSource
• Login must use DB access that can access all users (before I used separate schemas)
• Mail server must be dynamic per customer (see here, either by extension of the framework or by sending the mail oneself)
• Internal code changes for stuff that assumed to get back data for only one tenant

This is all possible IMHO. I also do see these three points:

1. Make sure Dynamic DataSources (same name, different result per customer), which might get cached, work as expected
2. Make sure Dynamic field title (this feature sponsorship) works as expected (same DataSource name, different result per customer)
3. Make sure the new feature you built in 12.0 caches only for one click of "upload" (strongly assume so)

Can you give you thoughts on 1/2/3? Do you see a problem here?
I'm sure that these two things would solve all potential issues:

1. Disable pooling like described here in server.properties OR
2. Make ALL DataSources dynamic and add them a suffix of "_xxx", where xxx is the customer number. Then only use this numbered access and rewrite all ID, foreignKey and includeFrom (more?) accordingly in the generator.

What way do you suggest. Am I missing something here? Do you have number on the performance penalty when disabling the pooling?
Do you know of a customer / project doing a similar thing with the framework?

Thank you & Best regards
Blama