Thanks for the hints. BTW - maybe you should open some kind of a plugin repository / wiki..
-----Original Message----- From: Jeff Butler [mailto:jeffgbut...@gmail.com] Sent: Tuesday, January 13, 2009 1:24 AM To: user-java@ibatis.apache.org Subject: Re: SQL selector It's not too much of a bad practice - many others (including Spring) take a similar approach to getting around the "official" API for iBATIS. I'm glad a plugin works for you! BTW - I'm excited about all the plugins people are writing for Ibator - stuff I never would have thought of doing. It's really great to see people using this mechanism. I also wanted to mention that you could make this same modification through the implementation of a custom extension to AbstractDAOTemplate. Either way should work in your case. Jeff Butler On Mon, Jan 12, 2009 at 10:41 AM, Ben Shory <be...@sapiens.com> wrote: > Since I'm trying to make it transparent as possible for the DBAs I > decided to create a plugin Which modifies all the DAO generated > methods to be like this for > example: > > Integer count = (Integer) > getSqlMapClientTemplate().queryForObject(getStmtId("table.ibatorgenera > te > d_countByExample"), example); > > ^^^^^^^^^^^ > This plugin also sets a custom super class which implments getStmtId - > something like this: > > protected String getStmtId(String stmtId) { > initStmtsIfNeeded(); > if(stmts.containsKey("specific-"+stmtId)) { > return "specific-"+stmtId; > } > return stmtId; > } > > Now my DBAs / clients may just drop-in their custom SQL with the > naming convention of specific-{table} for the sqlmap namespace > > To determine if the statement exsits I had to downcast to > SqlMapClientImpl, hope it's not too much of bad practice.. > > Thanks. > > > -----Original Message----- > From: Jeff Butler [mailto:jeffgbut...@gmail.com] > Sent: Monday, January 12, 2009 6:27 PM > To: user-java@ibatis.apache.org > Subject: Re: SQL selector > > iBATIS does not have a simple API for determining if a statement > exists > - so there's some difficulty with this idea. > > This reminds me of the design principle "prefer polymorphism over > instanceof". It seems to me that you could extend a generic DAO > implementation with a vendor specific implementation and override just > the methods that have vendor specific SQL. You would also have to > configure Spring so that you could pull out the vendor specific > implementation that you need. This seems easier to me - but I may not > understand the entirety of what you're trying to accomplish. > > Jeff Butler > > On Mon, Jan 12, 2009 at 3:19 AM, Ben Shory <be...@sapiens.com> wrote: >> It might be better to write a plugin that manipulates the generated >> method? >> >> -----Original Message----- >> From: Ben Shory [mailto:be...@sapiens.com] >> Sent: Monday, January 12, 2009 11:13 AM >> To: user-java@ibatis.apache.org >> Subject: SQL selector >> >> Hi, >> Before any statement execution, I would like to first check if it has >> a vendor specific implementation and execute it if so or the default >> one if not. >> My DAOs are generated as spring dao with ibator. >> I thought of doing something like - >> >> String stmtId = "table"+spec_postfix+".countByExample"; >> if(!statementExists(stmtId)) { >> stmtId = "table.countByExample"; >> } >> Integer count = (Integer) >> getSqlMapClientTemplate().queryForObject(stmtId, >> example); >> return count; >> >> Is this a good approach? >> Would I have to override SpringDAOTemplae? >> >> >
