On Thu, Jun 23, 2016 at 4:22 PM, Dunith Dhanushka <[email protected]> wrote:
> > > On Thu, Jun 23, 2016 at 3:46 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Amila, >> >> On Thu, Jun 23, 2016 at 11:52 AM, Amila Maha Arachchi <[email protected]> >> wrote: >> >>> All, >>> >>> 1. We should allow to decide whether to publish data in super tenant >>> mode or tenant mode >>> >> >> This is possible, but the problem is, it complicates the ESB analytics >> solution, where we will have to maintain two different versions which would >> implement the two scenarios. So IMO, it would be better to follow a single >> approach which would be overall best flexibility, which we discussed >> earlier, where we publish and manage data in tenants, but execute the Spark >> scripts in the super tenant. >> >> >>> 2. If its the ST mode, we deploy the car in ST space. >>> 3. Data gets published and stored in one table. i.e. no table per tenant >>> >> >> The current connectors, e.g. RDBMS / HBase etc.. use the mechanism of >> creating a table per analytics table/tenant. In those connectors, this >> behavior cannot be changed, where mainly there are technical difficulties >> in doing so also, when filtering out different tenant's data and all. >> Anyways, usually in database systems, there is no limit in the number of >> physical tables created and all. And also, you will not access these tables >> directly, but will communicate via the REST APIs if required. >> >> >>> 4. Spark runs against that table >>> >> >> With the new improvements, we anyway get similar type of an interface >> where the Spark script will automatically read data from all the tenants >> and process the data in one go. >> >> >>> 5. Dashboard should be a SaaS app which filters data from the analyzed >>> table. >>> >> >> I guess that maybe possible, but that will need some changes in the >> current dashboards. @Dunith, can you comment on this please. Also, is there >> any issue in deploying a dashboard per tenant?, which is the current >> situation. >> > > Hi Anjana, > Currently dashboards and other related artifacts are stored in tenant > aware manner. > > Dashboard definitions are stored in the logged in user's tenant registry > so that it'll be isolated only to that tenant. Gadget's read data through > analytics.jag which in turn filters data by looking at logged in user's > tenant domain. > > So I believe current implementation statisfies the requirements of a SaaS > app. > Can you add this to the roadmap for the next release please :). I see this will end up with another migration though :( > >> Cheers, >> Anjana. >> >> >>> >>> Can above be facilitated? >>> >>> Regards, >>> Amila. >>> >>> -- >>> *Amila Maharachchi* >>> Senior Technical Lead >>> WSO2, Inc.; http://wso2.com >>> >>> Blog: http://maharachchi.blogspot.com >>> Mobile: +94719371446 >>> >>> >> >> >> -- >> *Anjana Fernando* >> Senior Technical Lead >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> > > > > -- > Regards, > > Dunith Dhanushka, > Associate Technical Lead > WSO2 Inc, > > Mobile - +94 71 8615744 > Blog - *https://medium.com/@dunithd <https://medium.com/@dunithd>* > Twitter - @dunithd <http://twitter.com/dunithd> > -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
