Hi Sagara, Senaka, To send lifecycle checkpoint notifications we need get resources data which lifecycles are attached. Form those resources we have to filter against the lifecycles which includes checkpoints. Among them, we need to identify the resources which need to send notifications for the date and send them.
In the above approach, going through all the resource will be a high cost operation. Hence I introduced a new table to avoid iterating over all the resources. Entries required to send notifications are saved to the table when a lifecycle is attached, when a service is created(a default lifecycle is attached at this moment) and when a lifecycle is promoted. Table includes REG_PATH, NOTIFICATION_DATE, UUID, TENANT_ID, LC_NAME, LC_CHECKPOINT_ID. UUID is stored for the purpose of report generation in future. This lifecycle checkpoint notifications operates separately and sends notifications through a schedule tasks. In registry.xml we need to add a notification specific seperate datasource entry. When operating in a single node this point to the default WSO2_CARBON_DB and when operating in a cluster environment this needs to point to a separate shared datasource which includes this table. Thanks On Tue, Mar 3, 2015 at 10:39 AM, Sagara Gunathunga <[email protected]> wrote: > > > On Mon, Mar 2, 2015 at 7:06 PM, Senaka Fernando <[email protected]> wrote: > >> Hi Sagara, Prasanna, >> >> So, there were two issues here actually. >> >> 1. Firstly, this is the very first time we are going to introduce a >> new kind of DB for G-Reg. G-Reg, unlike many other products has a role of >> providing a federated repository against which everything else runs, so >> any >> DB or anything of that sort needs to be federated as well. So, though it >> may be easy enough for other products to introduce DBs it is not easy for >> G-Reg to do the same. My questions were to understand why we can't use the >> existing APIs and whether a new table/column is required for anything at >> all. >> >> @Prasanna, I also agree, you still haven't make your point clear why you > need a new table you have to justify your approach also elaborate how it > works in a clustered setup. > > @Senaka, I still didn't get clear picture about your concern about federated > repository, appreciate if you can elaborate more. > > >> >> 1. >> 2. If we have to introduce a DB however, we must, and that has to >> follow the GOV_ standard. This should be similar to API-M or IS in the way >> it is setup (i.e. separate datasource etc). >> >> So, given the explanation I think you guys have found the need for a DB, >> but it is a must to pay attention to the sharing aspects in addition to the >> naming aspects before going ahead with this. >> >> Thanks, >> Senaka. >> >> On Mon, Mar 2, 2015 at 7:22 AM, Sagara Gunathunga <[email protected]> >> wrote: >> >>> >>> >>> On Fri, Feb 27, 2015 at 7:43 PM, Prasanna Dangalla <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> I need to introduce a new table which is *only* needed for >>>> carbon-governance. AFAIK currently all the database scripts are in >>>> carbon-kernel [1]. AFAIU new table should be managed separately in >>>> carbon-governance with the introduction of a new prefix like GOV_. >>>> >>>> Feedback on this approach is highly appreciated. >>>> >>> >>> Here is my generic suggestion, G-Reg is a separate product and has lot >>> more features than Registry hence it's valid requirement to have own data >>> and own tables also GOV_ prefix in order to properly distinguish. IMO It is >>> incorrect to include G-Reg specific scripts into carbon-kernel script. We >>> already have this kind of separation in IS among user-mgt and identity >>> tables. >>> >>> Thanks ! >>> >>>> >>>> >>>> [1] - >>>> https://github.com/wso2/carbon4-kernel/tree/master/distribution/kernel/carbon-home/dbscripts >>>> >>>> Thanks >>>> -- >>>> Prasanna Dangalla >>>> Software Engineer, WSO2, Inc.; http://wso2.com/ >>>> lean.enterprise.middleware >>>> >>>> cell: +94 777 55 80 30 | +94 718 11 27 51 >>>> twitter: @prasa77 >>>> >>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >> >> >> -- >> >> >> *[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 >> > > > > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- Prasanna Dangalla Software Engineer, WSO2, Inc.; http://wso2.com/ lean.enterprise.middleware cell: +94 777 55 80 30 | +94 718 11 27 51 twitter: @prasa77
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
