Hi Shashika, So do you plan to create API methods on a per kernel component and per product component basis? I would find that rather scattered and hard to maintain. Though this looks justifiable from a kernel's point of view how would you repeat the same at a component level? My thought was that you'd be creating some new or adding to an existing component and you'll aggregate all tenant clean-up functionality in there making it easier to execute cross component operations. But, this is my personal viewpoint and it could be that I'm missing something.
Thanks, Senaka. On Wed, Feb 25, 2015 at 10:21 AM, Shashika Karunatilaka <[email protected]> wrote: > HI Senaka, > > Main reason for putting this method inside the kernel is, because when > creating a tenant all the user management data addition resides inside the > kernel, and all the registry related data addition reside inside the. and > each data deletion methods also reside inside the kernel, so this is the > main reason for putting this method inside kernel to delete all the tenant > registry data > > Thank you. > > On Wed, Feb 25, 2015 at 2:39 PM, Senaka Fernando <[email protected]> wrote: > >> Shashika, >> >> Apart from whatever tool that you build (again for a specific tenant >> administration purpose), who else will need to invoke this API method? My >> feeling is that this method does not belong inside the registry kernel or >> components. WDYT? >> >> Thanks, >> Senaka. >> >> >> On Wed, Feb 25, 2015 at 3:18 AM, Shashika Karunatilaka < >> [email protected]> wrote: >> >>> Hi Senaka/all >>> >>> To do delete the DB related data one option is to add a new method to >>> registry api called deleteAllTenantData(or suitable one) so i have to >>> implement this method on every dependent registry classes, Is it ok to >>> introduce new method to registry api? >>> >>> As i see when deleting a registry resources it goes to >>> UserRegistry->CacheBackRegistry->EmbeddedRegistry and it calls data >>> deletion DAOs. So in my case do i need to go through this flow to delete >>> the DB data or is it enough calling the DB queries in UserRegistry tenant >>> data deletion method >>> >>> Also i have another concern, as an example let say there is an >>> association related operation so to do that it will go above process I >>> mentioned and call the DAOs, those DAOs are implemented in a structural >>> manner where JDBCAssociationDAO implemented all the AssociationDAO >>> operation, in my case do i need to adhere to above structure where adding >>> all the registry related table data deletion methods to interface and >>> implement it or else is it ok to call the queries directly? >>> >>> Thank you. >>> >>> On Tue, Feb 24, 2015 at 10:52 AM, Danesh Kuruppu <[email protected]> >>> wrote: >>> >>>> Hi Shashika, >>>> >>>> In solr indexing, we store the resource by its tenant_id >>>> (indexed_document_id = resourcePath + "tenant" + tenantId) >>>> >>>> e.g: Assume you stored resource from the tenant1, indexed document id >>>> looks like below, >>>> >>>> "id": "/_system/governance/services/aaa/aaa/1.0.0*tenantId1*" >>>> >>>> You can get all resource store under tenantId using wildcard search. >>>> >>>> id:**tenantId1* >>>>> >>>> >>>> In Solr server, they have provided an api to delete by query. >>>> >>>> deleteByQuery(String query) >>>>> >>>> >>>> We can write new method in SolrClient to support this and call it from >>>> your component. Currently we only support delete index by resource id where >>>> we need resource path. >>>> >>>> Thanks >>>> Danesh >>>> >>>> On Mon, Feb 23, 2015 at 7:14 PM, Senaka Fernando <[email protected]> >>>> wrote: >>>> >>>>> Hi Shashika, >>>>> >>>>> I believe this is the only way to do this. There are several things to >>>>> note here. >>>>> >>>>> 1. In memory data - Ideally unloading the tenant should clean-up all >>>>> of this and if it does not there is an issue. >>>>> 2. DB data - all the tables have a tenant-id column. What you need is >>>>> a query to delete all records matching that tenant id. >>>>> 3. Solr Index etc and Registry Extensions deployed on the Filesystem - >>>>> These should be in corresponding folder/files structures either having a >>>>> tenant id or tenant domain. I don't recall this is as X, Y, and Z and I >>>>> don't think anyone else would do too. You can scan the code (Registry >>>>> Kernel, Registry Component and Governance Component) but it can be >>>>> tedious. >>>>> So, may be you can setup a tenant and grep for tenant-id/domain or grep >>>>> for >>>>> "-1234" and "carbon.super" in the filesystem. >>>>> 4. Other related data - The kernel alone uses the filesystem (inside >>>>> repository/deployment) which you might need to clean. There are temporary >>>>> files created that many require cleaning and also logs, if you are >>>>> interested in a full wipeout. The registry utilises some of these standard >>>>> features from the kernel and some information (mostly transient) can be >>>>> found in those. >>>>> >>>>> Appreciate some help from others in the G-Reg team to identify >>>>> anything I missed. >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> On Mon, Feb 23, 2015 at 6:02 AM, Shashika Karunatilaka < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Im in the process of deleting a tenant and all its related >>>>>> resources,so what i came up with is to delete all the resources related >>>>>> to >>>>>> that tenant using a direct DB call is there any other options to delete >>>>>> these data. >>>>>> and if i to continue on the above approach what are the areas i have >>>>>> to concern >>>>>> >>>>>> -- >>>>>> Shashika Prabath Karunatilaka, >>>>>> Software Engineer, >>>>>> WSO2, Inc: http://wso2.com/ >>>>>> mobile : +94 77 7487792 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >>>>> Solutions Architect; WSO2 Inc.; http://wso2.com >>>>> >>>>> >>>>> >>>>> *Member; Apache Software Foundation; http://apache.org >>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>> >>>>> >>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >>>>> http://linkedin.com/in/senakafernando >>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Danesh Kuruppu >>>> Software Engineer >>>> WSO2 Inc, >>>> Mobile: +94 (77) 1690552 >>>> >>> >>> >>> >>> -- >>> Shashika Prabath Karunatilaka, >>> Software Engineer, >>> WSO2, Inc: http://wso2.com/ >>> mobile : +94 77 7487792 >>> >> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >> Solutions Architect; WSO2 Inc.; http://wso2.com >> >> >> >> *Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > > > -- > Shashika Prabath Karunatilaka, > Software Engineer, > WSO2, Inc: http://wso2.com/ > mobile : +94 77 7487792 > -- *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
