Hi all, In the current issue tracker db we are not capturing an issue's lifecycle stage. But there is a gadget called "Issues by stage". Hence that information is needed. Shall we add a new column to the ISSUE table in the Issue tracker db?
Thanks. GayanD Gayan Dhanuska Software Engineer http://wso2.com/ Lean Enterprise Middleware Mobile 071 666 2327 Office Tel : 94 11 214 5345 Fax : 94 11 214 5300 Twitter : https://twitter.com/gayanlggd On Tue, Nov 12, 2013 at 10:33 AM, Gayan Dhanushka <[email protected]> wrote: > Hi Dimuthu, > > Will do and rewrite the gadgets. > > > > Gayan Dhanuska > Software Engineer > http://wso2.com/ > Lean Enterprise Middleware > > Mobile > 071 666 2327 > > Office > Tel : 94 11 214 5345 > Fax : 94 11 214 5300 > > Twitter : https://twitter.com/gayanlggd > > > On Tue, Nov 12, 2013 at 10:29 AM, Dimuthu Leelarathne > <[email protected]>wrote: > >> Hi Danushka, >> >> >> >> >> >> On Tue, Nov 12, 2013 at 10:08 AM, Gayan Dhanushka <[email protected]>wrote: >> >>> Hi Samisa, >>> >>> A document has to be maintained with the data and the sources that it >>> comes from. However more questions than answers arise when thinking about >>> what needs to be done. >>> >>> Yes we collect some data in appfactory, but if we take the issue tracker >>> as an example a customer may want to add JIRA or some other issue tracking >>> system. In that case there is no point of having gadgets for issue tracking >>> and changing the data sources to appfactory. It will be a whole different >>> scenario. >>> >>> Reading data from the appfactory registry may cause degradation of the >>> performance in the functionalities that uses the registry resources (number >>> of registry calls may increase since the dashboards talk to the registry as >>> well). >>> >>> >> It is much better than running hive to calculate already existing data. >> If it requires we can scale horizontally. We are designed to scale out. The >> theory is if there is a simple way MOST of the time it is the best way. And >> in this case it is better because we are saving a lot of crazy computing >> power. Imagine AF runs for years, and we spend 2/3 hours calculating an >> answer we already have in a database. >> >> +1 for rewriting to retrieve the existing answers. >> >> thanks, >> dimuthu >> >> >> >>> datafiles may become complex since it focuses on the data conversion >>> rather than building the dataset. >>> >>> So this re-modelling can be a good thing or sometimes it will be better >>> off to have the current implementation. Need to figure that out first >>> >> >> >>> >>> Thanks. >>> GayanD >>> >>> Gayan Dhanuska >>> Software Engineer >>> http://wso2.com/ >>> Lean Enterprise Middleware >>> >>> Mobile >>> 071 666 2327 >>> >>> Office >>> Tel : 94 11 214 5345 >>> Fax : 94 11 214 5300 >>> >>> Twitter : https://twitter.com/gayanlggd >>> >>> >>> On Sun, Nov 10, 2013 at 8:28 PM, Samisa Abeysinghe <[email protected]>wrote: >>> >>>> How do we keep track of what data is in BAM vs what data comes form >>>> other sources? >>>> >>>> I think it is a good idea to not replicate data, but the source of data >>>> need to be known all the time for help verify/test accuracy. >>>> >>>> Thanks, >>>> Samisa... >>>> >>>> >>>> Samisa Abeysinghe >>>> >>>> Vice President Training >>>> >>>> WSO2 Inc. >>>> http://wso2.com >>>> >>>> >>>> >>>> On Fri, Nov 8, 2013 at 2:54 PM, Gayan Dhanushka <[email protected]>wrote: >>>> >>>>> Hi All, >>>>> >>>>> There are some scenarios in appfactory where the data which needs to >>>>> be published to BAM is already captured by an underlying appfactory >>>>> database (e.g. issue tracker). Hence there is no need of publishing them >>>>> again to BAM and running a expensive hive query on top of it. But still >>>>> there has to be some Some observations are as follows. >>>>> >>>>> 1 ) Application creation and life cycle management details are >>>>> captured in the registry. But since registry resources are saved as a xml >>>>> string, the conversion of the xml to json is required in the jaggery >>>>> datafile. >>>>> 2 ) Issue tracker has a underlying mysql database. Hence data can be >>>>> directly pulled from the issue tracker database. >>>>> 3 ) Builds and commits data needs to be published to BAM anyway since >>>>> they are not captured by the appfactory databases. >>>>> >>>>> Is it good to read data directly from the registry databases? Will it >>>>> cause degradation in performance of the appfactory? Is it ok to change the >>>>> architecture and use underlying appfactory databases whenever possible? >>>>> WDYT? >>>>> >>>>> Thanks >>>>> GayanD. >>>>> >>>>> Gayan Dhanuska >>>>> Software Engineer >>>>> http://wso2.com/ >>>>> Lean Enterprise Middleware >>>>> >>>>> Mobile >>>>> 071 666 2327 >>>>> >>>>> Office >>>>> Tel : 94 11 214 5345 >>>>> Fax : 94 11 214 5300 >>>>> >>>>> Twitter : https://twitter.com/gayanlggd >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Architect & Product Lead of App Factory >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
