"but I would prefer to keep all SQLs in one place." I'm not sure what you mean by this. But, it is a discouraged practice to place all your statements into one file. It's bad for team development and organizationally.
As far as the requirements that are stated above you can accomplish these things now. You simply have to do some footwork ahead of time to determine which queries are common and which are database specific. Then you orgaize your sqlmap files accordingly and use the property substitution that clinton mentioned. The idea of exposing the internals of ibatis for these kinds of scenarios is something we want to take under considerable thought. We are an 80/20 tool. We don't claim to do all things for every situation. But, we will do our best to accomodate ideas that fit within our design goals. We do encourage and appreciate contributions. If you wish to make a contribution of thought or code we will happily review it and discuss it with you. If you expect to have free reign of the repository then I think you misunderstand OSS. I'm not aware of any OSS project that allows everyone in the world to commit to the repository unchecked. That said, I think the solution for this _may_ be to expose SqlMap "meta data" so that you can make decisions outside of the framework regarding what you will call. This should be used judiciously and remain hidden within the DAO layer. But, it may be valuable to come up with a list of information that can be exposed as read-only sqlmap meta-data. In regards to your encryption... you can write your own datasource implementation or wrap another datasource and have it interpret the encrypted password. That really has nothing to do with IBatis. All IBatis would care about is that it has _a_ value for the password. Besides it wouldn't seem that you would not want your password encryption seed to exist in the code that you are distributing. Most likely you would want that to remain on a higher, more trusted and secure level, such as the web server via JNDI. Brandon On Mon, 28 Mar 2005 22:00:19 +0200 (CEST), Vadim Pesochinskiy (JIRA) <[email protected]> wrote: > [ > http://issues.apache.org/jira/browse/IBATIS-87?page=comments#action_61668 ] > > Vadim Pesochinskiy commented on IBATIS-87: > ------------------------------------------ > > How did you implement this? Do you parse the SqlMap config in your code? I am > hesitating doing that, because changes in config will make your code not > usable. I would not mind doing this, if it was available in the next release > instead of being my "proprietary" extension. > > Current solution, which Clinton described above, is acceptable, but I would > prefer to keep all SQLs in one place. > > This is very unfortunate that one cannot easily add contributions to the > project, because it kind of undermines the value of open source... On the > other hand, managing the scope is more important than ability for everyone to > add code. > > > Add notion of DB specific SQL statements > > ---------------------------------------- > > > > Key: IBATIS-87 > > URL: http://issues.apache.org/jira/browse/IBATIS-87 > > Project: iBatis for Java > > Type: New Feature > > Components: SQL Maps > > Environment: Any > > Reporter: Vadim Pesochinskiy > > Priority: Minor > > > > > This is probably not very impressive idea, but I will throw it in anyway. > > What if we add a DatabaseType property and have SqlMap lookup proper query > > for it in the same manner as Java internationalization works. DB type > > attribute can have an arbitrary value, which is only used get proper query. > > E.g. > > Queries: > > getOrder.sqlserver > > getOrder > > If DataBaseType is 'sqlserver' - 'getOrder.sqlserver' query is picked, if > > DataBaseType=oracle or DataBaseType=postgres 'getOrder' sql will be > > executed. > > I can implement it, if you don't mind :). Thanks. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > If you want more information on JIRA, or have a bug to report see: > http://www.atlassian.com/software/jira > >
