I am actually in favour of what Ruwan is suggesting. 1. When a problem comes we usually start by looking at the particular query. There is no need to look at all queries together.
2. Having the query close to rest of the jdbc code is easier. 3. Regardless of where it is, all queries should be formatted for readability than putting it as a single liner string On Oct 28, 2016 7:27 AM, "Selvaratnam Uthaiyashankar" <[email protected]> wrote: > Do we have any requirements to see all queries together? If so, defining > in a single place would be easy. However, I am not sure whether we have > used that requirement ever. We normally look at the query local to the > method? If so, I am +1 for Ruwan's proposal. Being local constant to the > method seems good. > > On Thu, Oct 27, 2016 at 9:42 PM, Sagara Gunathunga <[email protected]> > wrote: > >> >> Personally I don't have strong preference on one style over other, what >> mostly important for me is maintain one style consistently within the >> product and if possible across the company. >> >> I'm adding few other people for their opinion. >> >> Thanks ! >> >> On Thu, Oct 27, 2016 at 5:34 PM, Ruwan Abeykoon <[email protected]> wrote: >> >>> Hi Devs, >>> We have been following a convention to put Database query string in a >>> constant elsewhere in the code when performing DB CRUD operations. >>> >>> e.g. >>> >>> try { >>> String sqlStmt = IdPManagementConstants.SQLQueries.GET_IDP_BY_NAME_SQL; >>> prepStmt = dbConnection.prepareStatement(sqlStmt); >>> prepStmt.setInt(1, tenantId); >>> prepStmt.setInt(2, MultitenantConstants.SUPER_TENANT_ID); >>> prepStmt.setString(3, idPName); >>> rs = prepStmt.executeQuery(); >>> >>> ... >>> >>> >>> However I would propose to keep the query in the same location as the SQL >>> parameter binding and result set reading. Shall we make it within local >>> final variable(constant) in the method itself. >>> >>> The advantage is that the Query is visible on the same screen as it is >>> being used. This reduces number of screen flips. Also remembering the query >>> at somewhere else is error prone. >>> >>> This also help easy review and do query optimizations. >>> >>> >>> e.g. >>> >>> final String INSERT_IDP_SQL = "INSERT INTO IDP (NAME, DISPLAY_NAME, >>> DESCRIPTION) VALUES(?,?,?)"; >>> >>> this.jdbcTemplate.executeUpdate(INSERT_IDP_SQL, (preparedStatement, bean) >>> -> { >>> MetaIdentityProvider metaIdentityProvider = >>> identityProvider.getMetaIdentityProvider(); >>> preparedStatement.setString(1, metaIdentityProvider.getName()); >>> preparedStatement.setString(2, metaIdentityProvider.getDisplayName()); >>> preparedStatement.setString(3, metaIdentityProvider.getDescription()); >>> >>> ... >>> >>> >>> Please note that they are the same in terms of memory use and >>> performance wise as compiler make them constants. >>> Putting them as constants serve no purpose as the query will never be >>> reused in proper designed Data Access layer. We should reuse the code, not >>> the query. >>> >>> WDYT? >>> >>> -- >>> >>> *Ruwan Abeykoon* >>> *Associate Director/Architect**,* >>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>> *lean.enterprise.middleware.* >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Associate Director / Architect; 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 >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 774895474 >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
