Hi Prabath / Dilan, If you refer 8th point [1] there won't be any problems with deployment scenarios ...etc. I think currently you guys can completely ignore IDENTITY db script and go with APIM db script there are only few exceptional situations where you want to execute both APIM db script and IDENTITY db script. If you find such a scenario you can resolve it with instructions provided in 8th point of [1]. Let's see Johann and Nuwan suggestion from design point of view.
[1] https://docs.wso2.com/display/CLUSTER420/Configuring+WSO2+Identity+Server+as+the+Key+Manager On Mon, Feb 23, 2015 at 12:59 PM, Dilan Udara Ariyaratne <[email protected]> wrote: > Hi Gayan, > > What you are saying is true and off-course this not an issue when > considering the higher-level functionality of the components. > > However my major concern is, in a deployment scenario, when a customer is > trying to manually execute the scripts to > get the databases ready, having this duplication will cause errors to pop > up at the SQL Prompt which is ugly and that might even make > the customer panic on whether he is doing any wrong thing. > > Why can't we have those IDENTITY Tables duplicated in APIM Script within > the IDENTITY Script itself? > > Regards, > Dilan. > > > > *Dilan U. Ariyaratne* > Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94775149066 > lean . enterprise . middleware > > On Mon, Feb 23, 2015 at 12:28 PM, Gayan Gunawardana <[email protected]> > wrote: > >> >> >> On Mon, Feb 23, 2015 at 6:29 AM, Dilan Udara Ariyaratne <[email protected]> >> wrote: >> >>> Hi Gayan, >>> >>> Does this mean that the ORACLE Script residing inside "identity" >>> directory in <emm-script>/dbscripts is redundant >>> and not necessary to have? >>> >> >> APIM db script does not contain all tables in IDENTITY db script so >> better to keep IDENTITY db script too. >> >>> >>> Thanks. >>> >>> >>> >>> *Dilan U. Ariyaratne* >>> Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> Mobile: +94775149066 >>> lean . enterprise . middleware >>> >>> On Sun, Feb 22, 2015 at 11:02 AM, Gayan Gunawardana <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Feb 20, 2015 at 11:50 PM, Dilan Udara Ariyaratne < >>>> [email protected]> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> While checking the database scripts of both API Manager and IDENTITY >>>>> modules inside EMM 1.1.0, >>>>> it has been found out that there are some DB Table definitions of >>>>> IDENTITY repeated inside APIM DB Scripts >>>>> as follows. >>>>> >>>>> IDN_BASE_TABLE >>>>> IDN_OAUTH_CONSUMER_APPS >>>>> IDN_OAUTH1A_REQUEST_TOKEN >>>>> IDN_OAUTH1A_ACCESS_TOKEN >>>>> IDN_OAUTH2_AUTHORIZATION_CODE >>>>> IDN_OAUTH2_ACCESS_TOKEN >>>>> IDN_OPENID_USER_RPS >>>>> IDN_THRIFT_SESSION >>>>> >>>>> Do we have any valid reasons to have such duplication of these table >>>>> definitions inside >>>>> both APIM and IDENTITY DB Scripts? >>>>> >>>> check EMM 1.1.0 identity.xml DataSource. I guess it is jdbc/WSO2AM_DB >>>> so for IDENTITY and APIM you are using tables inside APIM db script. Even >>>> though both DB scripts contains IDN_* tables there is no such a >>>> duplication. >>>> >>>> >>>>> >>>>> Appreciate your feedback on this. >>>>> >>>>> Thanks. >>>>> >>>>> *Dilan U. Ariyaratne* >>>>> Software Engineer >>>>> WSO2 Inc. <http://wso2.com/> >>>>> Mobile: +94775149066 >>>>> lean . enterprise . middleware >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Gayan Gunawardana >>>> Software Engineer; WSO2 Inc.; http://wso2.com/ >>>> Email: [email protected] >>>> Mobile: +94 (71) 8020933 >>>> >>> >>> >> >> >> -- >> Gayan Gunawardana >> Software Engineer; WSO2 Inc.; http://wso2.com/ >> Email: [email protected] >> Mobile: +94 (71) 8020933 >> > > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
