Hi Sagara, I did not mean a specific scenario when I said federated, but the concept in general. For example, say you have a central registry and a specific registry running at several local sites. If I want lifecycle management and other functionality across these, in 4.6.0, I just need to share the DBs and setup the mounts properly. It may not work for every use-case, but at least from a deployment architecture point of view it is properly setup. With a new datatabase in G-Reg 5.0.0, if we have a similar setup, this new DB should also be federated across the central and local sites. Without a proper strategy (such as registry mounting), it is not going to be easy.
Hi Prasanna, While the approach can be a solution, I'm still not convinced it is the best or whether it is the only solution. Aren't lifecycle checkpoints captured as properties of a resource? If so, it is just a matter of writing a good query that can do a SELECT to return a paginated result set back for you. Since the query is scheduled, to avoid the task unwantedly running queries as and when needed, you need a handler to track whether the resource was updated or not. This is all that is needed. Please explain if your requirement cannot be met by this? Also, irrespective of the requirement, the approach is not right (i.e. according to our conventions). - Column names have conventions. - You can't have yet another UUID, it has to be deducible from any existing unique identifiers or you'll pay the price the day you want to migrate. - You can't touch registry.xml if this is a new DB. On a separate front, everything in G-Reg that has no connection to the registry schema must be removed from that configuration file. It doesn't really make sense. - How does your notification sending work if G-Reg is clustered (i.e. two nodes pointing at the same table)? Thanks, Senaka. On Tue, Mar 3, 2015 at 6:48 AM, Prasanna Dangalla <[email protected]> wrote: > 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 > -- *[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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
