Hi Senaka, In previous implementation I did, the checkpoints were not captured as resource properties. They were stored in a table. Now I included them as resource properties as you said. Hence no need of introducing a new table. Thanks for the suggestion. Property search was done using the solar advance search feature.
Thanks On Tue, Mar 3, 2015 at 2:25 PM, Senaka Fernando <[email protected]> wrote: > 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 <%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 > -- 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
