From dmorrison@example.com Tue Nov 01 08:33:18 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 47554 invoked from network); 1 Nov 2005 08:33:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2005 08:33:18 -0000 Received: (qmail 33914 invoked by uid 500); 1 Nov 2005 08:33:18 -0000 Delivered-To: dmorrison@example.com Received: (qmail 33900 invoked by uid 500); 1 Nov 2005 08:33:17 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 33889 invoked by uid 500); 1 Nov 2005 08:33:17 -0000 Delivered-To: dmorrison@example.com Received: (qmail 33884 invoked by uid 99); 1 Nov 2005 08:33:17 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Nov 2005 00:33:16 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 8F8BC598 for <dmorrison@example.com>; Tue, 1 Nov 2005 09:32:55 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Tue, 1 Nov 2005 09:32:55 +0100 (CET) From: "Iwao AVE! (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-213) SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps. Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N SELECT statement returns unexpected result when 'groupBy' and 'nullValue' are specified in resultMaps. ------------------------------------------------------------------------------------------------------ Key: IBATIS-213 URL: http://issues.apache.org/jira/browse/IBATIS-213 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.5 Environment: PowerMac G5 1.8GHz dual, 2.25GB RAM, Mac OS X 10.4.2 Using SqlMaps from tomcat via spring framework. Reporter: Iwao AVE! [Preparation] -- Database CREATE TABLE parent ( parentId, parentName ); CREATE TABLE child ( childId, parentId, childName, childAge ); INSERT INTO parent ( parentId, parentName ) VALUES ( 1, 'Mr Parent' ); -- Java classes. public class Parent { private int parentId; private String parentName; private List childList; // accessor methods... } public class Child { private int childId; private String childName; private int childAge; // accessor methods... } --SqlMap. <sqlMap namespace="Family"> <resultMap id="parentResult" class="Parent" groupBy="parentId"> <result property="parentId" column="parentId"/> <result property="parentName" column="parentName"/> <result property="childList" resultMap="Family.childResult"/> </resultMap> <resultMap id="childResult" class="Child"> <result property="childId" column="childId"/> <result property="childName" column="childName"/> <result property="childAge" column="childAge" nullValue="0"/> </resultMap> <select id="getParent" resultMap="parentResult" parameterClass="int"> SELECT parent.parentId, parent.parentName, child.childId, child.childName, child.childAge FROM parent LEFT JOIN child ON parent.parentId = child.parentId WHERE parent.parentId = #value# </select> </sqlMap> -- [Test] Executing statement "getParent" with parameter '1'. [Expected result] Query returns 1 'Parent' object and 'childList' property of it is empty (doesn't mean null). [Actual result] The 'childList' property of the returned 'Parent' contains 1 'Child' object. [Additional information] If 'nullValue' is not specified in 'childResult', it works as expected. But this, of course, causes an error if there is a row in the 'child' table and the 'childAge' column is null. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Tue Nov 01 08:51:18 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 53820 invoked from network); 1 Nov 2005 08:51:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2005 08:51:17 -0000 Received: (qmail 55038 invoked by uid 500); 1 Nov 2005 08:51:17 -0000 Delivered-To: dmorrison@example.com Received: (qmail 55026 invoked by uid 500); 1 Nov 2005 08:51:17 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 55015 invoked by uid 500); 1 Nov 2005 08:51:17 -0000 Delivered-To: dmorrison@example.com Received: (qmail 55012 invoked by uid 99); 1 Nov 2005 08:51:17 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Nov 2005 00:51:16 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id D6FB6598 for <dmorrison@example.com>; Tue, 1 Nov 2005 09:50:55 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Tue, 1 Nov 2005 09:50:55 +0100 (CET) From: "Gilles Bayon (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATISNET-123) Support for nested properties in Result Map Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Support for nested properties in Result Map ------------------------------------------- Key: IBATISNET-123 URL: http://issues.apache.org/jira/browse/IBATISNET-123 Project: iBatis for .NET Type: Improvement Components: DataMapper Reporter: Gilles Bayon Assigned to: Gilles Bayon Priority: Minor Fix For: DataMapper 1.3 See http://dmorrison@example.com/msg00321.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Tue Nov 01 08:51:18 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 53859 invoked from network); 1 Nov 2005 08:51:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2005 08:51:18 -0000 Received: (qmail 55257 invoked by uid 500); 1 Nov 2005 08:51:18 -0000 Delivered-To: dmorrison@example.com Received: (qmail 55156 invoked by uid 500); 1 Nov 2005 08:51:18 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 55145 invoked by uid 500); 1 Nov 2005 08:51:18 -0000 Delivered-To: dmorrison@example.com Received: (qmail 55140 invoked by uid 99); 1 Nov 2005 08:51:17 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Nov 2005 00:51:17 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id BFA6959A for <dmorrison@example.com>; Tue, 1 Nov 2005 09:50:56 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Tue, 1 Nov 2005 09:50:56 +0100 (CET) From: "Gilles Bayon (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Closed: (IBATISNET-123) Support for nested properties in Result Map In-Reply-To: <dmorrison@example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/IBATISNET-123?page=all ] Gilles Bayon closed IBATISNET-123: ---------------------------------- Resolution: Fixed Close in SVN 328694 > Support for nested properties in Result Map > ------------------------------------------- > > Key: IBATISNET-123 > URL: http://issues.apache.org/jira/browse/IBATISNET-123 > Project: iBatis for .NET > Type: Improvement > Components: DataMapper > Reporter: Gilles Bayon > Assignee: Gilles Bayon > Priority: Minor > Fix For: DataMapper 1.3 > > See > http://dmorrison@example.com/msg00321.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Wed Nov 02 15:19:30 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 50484 invoked from network); 2 Nov 2005 15:19:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Nov 2005 15:19:24 -0000 Received: (qmail 33840 invoked by uid 500); 2 Nov 2005 15:19:21 -0000 Delivered-To: dmorrison@example.com Received: (qmail 33799 invoked by uid 500); 2 Nov 2005 15:19:20 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 33787 invoked by uid 500); 2 Nov 2005 15:19:19 -0000 Delivered-To: dmorrison@example.com Received: (qmail 33783 invoked by uid 99); 2 Nov 2005 15:19:19 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2005 07:19:19 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 112FF5BD for <dmorrison@example.com>; Wed, 2 Nov 2005 16:18:58 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Wed, 2 Nov 2005 16:18:58 +0100 (CET) From: "Daniel Silva (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-214) Make parameter maps work like inline parameters, no matter count and/or order Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Make parameter maps work like inline parameters, no matter count and/or order ----------------------------------------------------------------------------- Key: IBATIS-214 URL: http://issues.apache.org/jira/browse/IBATIS-214 Project: iBatis for Java Type: New Feature Components: SQL Maps Versions: 2.1.5 Environment: iBATIS SQL Maps 83.161.120.1552 Reporter: Daniel Silva When using parameter maps and in your statement you use same parameter more than once, you need to redeclare this parameter at your parameter map tied to order and count of those parameters in your mapped statement. So, in situations like this: <select id="foo" parameterMap="fooMap"> select * from foo a, bar b where b.fooId = a.id and a.myfield = ? and b.anotherfield = ? </select> My fooMap parameter map must look like this: <parameterMap id="fooMap" class="com.foo.Blah"> <parameter property="param"/> <parameter property="param"/> </parameterMap> Proposal is to change the way parameter maps work currently to something like inline parameters: <parameterMap id="fooMap" class="com.foo.Blah"> <parameter property="param"/> </parameterMap> <select id="foo" parameterMap="fooMap"> select * from foo a, bar b where b.fooId = a.id and a.myfield = #param# and b.anotherfield = #param# </select> Maybe it could be useful to add an attribute to the <parameter/> element to mimic the way result maps work. So we'd have something like: <parameter property="param" inline="blah"/> and then: <select id="foo" parameterMap="myMap"> select * from foo a, bar b where b.fooId = a.id and a.myfield = #blah# and b.anotherfield = #blah# </select> Not sure 'inline' would be such a good name for this attribute so do what you think is the best. Any comments appreciated. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Thu Nov 03 00:43:18 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 65509 invoked from network); 3 Nov 2005 00:43:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Nov 2005 00:43:18 -0000 Received: (qmail 76334 invoked by uid 500); 3 Nov 2005 00:43:18 -0000 Delivered-To: dmorrison@example.com Received: (qmail 76232 invoked by uid 500); 3 Nov 2005 00:43:17 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 76221 invoked by uid 500); 3 Nov 2005 00:43:17 -0000 Delivered-To: dmorrison@example.com Received: (qmail 76217 invoked by uid 99); 3 Nov 2005 00:43:17 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2005 16:43:16 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id AA6DC5BF for <dmorrison@example.com>; Thu, 3 Nov 2005 01:42:55 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Thu, 3 Nov 2005 01:42:55 +0100 (CET) From: "Paul Benedict (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-215) BSF for dynamic queries Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N BSF for dynamic queries ----------------------- Key: IBATIS-215 URL: http://issues.apache.org/jira/browse/IBATIS-215 Project: iBatis for Java Type: New Feature Components: SQL Maps Reporter: Paul Benedict While the list of tags to form dynamic queries is suitable, they are limiting because they stop the "dreamer from dreaming." More complex logic cannot be addressed without creating a barrage of new tags. I propose a new tag called <script> (or something similar) which is backed by the Apache Bean Scripting Framework. The parameter map passed in to the <statement> should load it into the scripting Interpreter object and expose it for the <script> tag so that dynamic Java or JavaScript can return boolean parameters. Obviously there is a performance hit for this and the previous tags would be much simpler for common boolean operations, but the sky is the limit when it comes to what you can compare inside the script. Example: <select id="dynamicGetAccountList" cacheModel="resultMap="account-result" > select * from ACCOUNT <script><expression>obj.id != null && obj.id > 0 && obj.lastName.startsWith("B")"</expression> where ACC_ID = #id# and ACC_NAME = #lastName# </script> order by ACC_LAST_NAME </select> If BSF is not suitable, please look into OGNL which is popular within Apache Tapestry and is a very good alternative. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Thu Nov 03 05:02:19 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 59005 invoked from network); 3 Nov 2005 05:02:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Nov 2005 05:02:19 -0000 Received: (qmail 6283 invoked by uid 500); 3 Nov 2005 05:02:18 -0000 Delivered-To: dmorrison@example.com Received: (qmail 6157 invoked by uid 500); 3 Nov 2005 05:02:17 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 6110 invoked by uid 500); 3 Nov 2005 05:02:17 -0000 Delivered-To: dmorrison@example.com Received: (qmail 6080 invoked by uid 99); 3 Nov 2005 05:02:17 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2005 21:02:16 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id C44FD232 for <dmorrison@example.com>; Thu, 3 Nov 2005 06:01:55 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Thu, 3 Nov 2005 06:01:55 +0100 (CET) From: "Paul Benedict (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-216) Optional property in resultmap Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Optional property in resultmap ------------------------------ Key: IBATIS-216 URL: http://issues.apache.org/jira/browse/IBATIS-216 Project: iBatis for Java Type: New Feature Reporter: Paul Benedict I would find it useful to have optional properties in a resultmap. I don't want to have specialized maps for different queries which may return different number of columns for the same object type. I think an optional attribute would be helpful: <result property="description" column="DESC" optional="true" /> -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Thu Nov 03 23:27:11 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 23088 invoked from network); 3 Nov 2005 23:27:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Nov 2005 23:27:11 -0000 Received: (qmail 25569 invoked by uid 500); 3 Nov 2005 23:27:11 -0000 Delivered-To: dmorrison@example.com Received: (qmail 25537 invoked by uid 500); 3 Nov 2005 23:27:10 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 25526 invoked by uid 500); 3 Nov 2005 23:27:10 -0000 Delivered-To: dmorrison@example.com Received: (qmail 25523 invoked by uid 99); 3 Nov 2005 23:27:10 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2005 15:27:10 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 91FAA232 for <dmorrison@example.com>; Fri, 4 Nov 2005 00:26:49 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Fri, 4 Nov 2005 00:26:49 +0100 (CET) From: "DongGuk Lee (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-217) I would like to see korean document on iBATIS website's document page Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I would like to see korean document on iBATIS website's document page --------------------------------------------------------------------- Key: IBATIS-217 URL: http://issues.apache.org/jira/browse/IBATIS-217 Project: iBatis for Java Type: Wish Components: Documentation Reporter: DongGuk Lee Korean SQLMaps users can't look for korean SQLMaps document on following URL. http://ibatis.apache.org/downloads.html I would like to see korean SQLMaps document on iBATIS website's document page please upload korean document to http://ibatis.apache.org/downloads.html -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Fri Nov 04 05:26:22 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 42069 invoked from network); 4 Nov 2005 05:26:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 05:26:22 -0000 Received: (qmail 8257 invoked by uid 500); 4 Nov 2005 05:26:21 -0000 Delivered-To: dmorrison@example.com Received: (qmail 8244 invoked by uid 500); 4 Nov 2005 05:26:21 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 8233 invoked by uid 500); 4 Nov 2005 05:26:21 -0000 Delivered-To: dmorrison@example.com Received: (qmail 8230 invoked by uid 99); 4 Nov 2005 05:26:20 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2005 21:26:18 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 9B448229 for <dmorrison@example.com>; Fri, 4 Nov 2005 06:25:57 +0100 (CET) Message-ID: <{{EMAIL+PHONE}}> Date: Fri, 4 Nov 2005 06:25:57 +0100 (CET) From: "Paul Benedict (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-Reply-To: <{{EMAIL+PHONE}}> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/IBATIS-143?page=comments#action_12356748 ] Paul Benedict commented on IBATIS-143: -------------------------------------- I prefer this feature too. The problem is that I like my SQL to be listed longwise, with each column on its own line and so it can become stretched with many useless whitespaces when listed out on one line. Not to mention, because the SQL is in an XML file, all that identation is preserved too. I wish it could be removed. I know many XML parsers have a feature to trim down the padding to one white space on each side. That would be so much better!! > Remove blanks in SQL > -------------------- > > Key: IBATIS-143 > URL: http://issues.apache.org/jira/browse/IBATIS-143 > Project: iBatis for Java > Type: Improvement > Components: SQL Maps > Environment: all > Reporter: Steffen Legler > Priority: Minor > > Dynamically built SQL-Statements include a lot of blanks when using conditional > elements like <isEqual>. The database doesn't care, but for logging it would be > nice to have a well written sql-statement, e.g. : > <update id="update" parameterClass="paramClass"> > update schema.table1 set > <isEqual property="listId" compareValue="1"> > column1 = #value# > </isEqual> > <isEqual property="listId" compareValue="2"> > column2 = #value# > </isEqual> > where id=#instanceId# > </update> > > The result of a statement looks like this; > update schema.table1 set column1 = '123' where id = 1000 > > For readability it would be nice to have something like this: > update schema.table1 set column1 = '123' where id = 1000 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Fri Nov 04 09:10:43 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 42733 invoked from network); 4 Nov 2005 09:10:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 09:10:43 -0000 Received: (qmail 16022 invoked by uid 500); 4 Nov 2005 09:10:42 -0000 Delivered-To: dmorrison@example.com Received: (qmail 15999 invoked by uid 500); 4 Nov 2005 09:10:42 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 15986 invoked by uid 500); 4 Nov 2005 09:10:42 -0000 Delivered-To: dmorrison@example.com Received: (qmail 15983 invoked by uid 99); 4 Nov 2005 09:10:41 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 01:10:41 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id A2F77232 for <dmorrison@example.com>; Fri, 4 Nov 2005 10:10:20 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Fri, 4 Nov 2005 10:10:20 +0100 (CET) From: =?UTF-8?Q?Peter_K=C3=B6hler_=28JIRA=29?= <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-Reply-To: <{{EMAIL+PHONE}}> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/IBATIS-143?page=3Dcomments#actio= n_12356755 ]=20 Peter K=C3=B6hler commented on IBATIS-143: ------------------------------------- I don=C2=B4t like this idea because this is a typical deployment task and b= uild tools like ant have possibilities (http://ant.apache.org/manual/Option= alTasks/replaceregexp.html) where you can do this kind of stuff and more li= ke removing comments, empty lines, fix crlf and so much more. Greetings from Frankfurt Peter K=C3=B6hler > Remove blanks in SQL > -------------------- > > Key: IBATIS-143 > URL: http://issues.apache.org/jira/browse/IBATIS-143 > Project: iBatis for Java > Type: Improvement > Components: SQL Maps > Environment: all > Reporter: Steffen Legler > Priority: Minor > > Dynamically built SQL-Statements include a lot of blanks when using condi= tional > elements like <isEqual>. The database doesn't care, but for logging it wo= uld be > nice to have a well written sql-statement, e.g. : > <update id=3D"update" parameterClass=3D"paramClass"> > =09update schema.table1 set=20 > =09=09=09<isEqual property=3D"listId" compareValue=3D"1"> > =09=09=09column1 =3D #value#=09=09=09=09=09=09 > =09=09=09</isEqual> =09 > =09=09=09<isEqual property=3D"listId" compareValue=3D"2"> > =09=09=09column2 =3D #value#=09=09=09=09=09=09 > =09=09=09</isEqual> =09=09=09 > =09=09where id=3D#instanceId# > </update> > =20 > The result of a statement looks like this; > =09update schema.table1 set column1 =3D '123' = where id =3D 1000 > =09=09=09 > For readability it would be nice to have something like this: > update schema.table1 set column1 =3D '123' where id =3D 1000 --=20 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Fri Nov 04 11:12:45 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 3797 invoked from network); 4 Nov 2005 11:12:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 11:12:44 -0000 Received: (qmail 61237 invoked by uid 500); 4 Nov 2005 11:12:44 -0000 Delivered-To: dmorrison@example.com Received: (qmail 61208 invoked by uid 500); 4 Nov 2005 11:12:42 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 61196 invoked by uid 500); 4 Nov 2005 11:12:42 -0000 Delivered-To: dmorrison@example.com Received: (qmail 61193 invoked by uid 99); 4 Nov 2005 11:12:42 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 03:12:42 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 32013232 for <dmorrison@example.com>; Fri, 4 Nov 2005 12:12:21 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Fri, 4 Nov 2005 12:12:21 +0100 (CET) From: "Steffen Legler (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-Reply-To: <{{EMAIL+PHONE}}> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/IBATIS-143?page=comments#action_12356767 ] Steffen Legler commented on IBATIS-143: --------------------------------------- I think, you don't understand the issue. Dynamic built SQL has nothing to do with deployment. The SQL-statements are built during runtime and will be shown without any removals of blanks in the log4j-logger. For debugging possible errors or for presenting the logger-messages it is more comfortable to have a sql-statements with only one blank and not 2 or more blanks between two words. Greetings from Hannover, Steffen > Remove blanks in SQL > -------------------- > > Key: IBATIS-143 > URL: http://issues.apache.org/jira/browse/IBATIS-143 > Project: iBatis for Java > Type: Improvement > Components: SQL Maps > Environment: all > Reporter: Steffen Legler > Priority: Minor > > Dynamically built SQL-Statements include a lot of blanks when using conditional > elements like <isEqual>. The database doesn't care, but for logging it would be > nice to have a well written sql-statement, e.g. : > <update id="update" parameterClass="paramClass"> > update schema.table1 set > <isEqual property="listId" compareValue="1"> > column1 = #value# > </isEqual> > <isEqual property="listId" compareValue="2"> > column2 = #value# > </isEqual> > where id=#instanceId# > </update> > > The result of a statement looks like this; > update schema.table1 set column1 = '123' where id = 1000 > > For readability it would be nice to have something like this: > update schema.table1 set column1 = '123' where id = 1000 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Fri Nov 04 16:09:37 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 55906 invoked from network); 4 Nov 2005 16:09:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 16:09:35 -0000 Received: (qmail 27001 invoked by uid 500); 4 Nov 2005 16:09:34 -0000 Delivered-To: dmorrison@example.com Received: (qmail 26982 invoked by uid 500); 4 Nov 2005 16:09:33 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 26971 invoked by uid 99); 4 Nov 2005 16:09:33 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:09:33 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [83.161.120.155] (HELO brmea-mail-3.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:09:28 -0800 Received: from fe-amer-09.sun.com ([83.161.120.155]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jA4G9C3F027075 for <dmorrison@example.com>; Fri, 4 Nov 2005 09:09:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <dmorrison@example.com> (original mail from dmorrison@example.com) for dmorrison@example.com; Fri, 04 Nov 2005 09:09:12 -0700 (MST) Received: from [83.161.120.155] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <dmorrison@example.com> for dmorrison@example.com; Fri, 04 Nov 2005 09:09:11 -0700 (MST) Date: Fri, 04 Nov 2005 09:11:02 -0700 From: Nathan Maves <dmorrison@example.com> Subject: Re: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-reply-to: <dmorrison@example.com> Sender: dmorrison@example.com To: dmorrison@example.com Message-id: <dmorrison@example.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <dmorrison@example.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I think that this would be a nice to have. You would have to do a regular exp match to substitute one space for two or more spaces. Nathan On Nov 4, 2005, at 4:12 AM, Steffen Legler (JIRA) wrote: > [ http://issues.apache.org/jira/browse/IBATIS-143? > page=comments#action_12356767 ] > > Steffen Legler commented on IBATIS-143: > --------------------------------------- > > I think, you don't understand the issue. Dynamic built SQL has > nothing to do with deployment. The SQL-statements are built during > runtime and will be shown without any removals of blanks in the > log4j-logger. For debugging possible errors or for presenting the > logger-messages it is more comfortable to have a sql-statements > with only one blank and not 2 or more blanks between two words. > > Greetings from Hannover, > > Steffen > >> Remove blanks in SQL >> -------------------- >> >> Key: IBATIS-143 >> URL: http://issues.apache.org/jira/browse/IBATIS-143 >> Project: iBatis for Java >> Type: Improvement >> Components: SQL Maps >> Environment: all >> Reporter: Steffen Legler >> Priority: Minor > >> >> Dynamically built SQL-Statements include a lot of blanks when >> using conditional >> elements like <isEqual>. The database doesn't care, but for >> logging it would be >> nice to have a well written sql-statement, e.g. : >> <update id="update" parameterClass="paramClass"> >> update schema.table1 set >> <isEqual property="listId" compareValue="1"> >> column1 = #value# >> </isEqual> >> <isEqual property="listId" compareValue="2"> >> column2 = #value# >> </isEqual> >> where id=#instanceId# >> </update> >> >> The result of a statement looks like this; >> update schema.table1 set column1 = >> '123' where id = 1000 >> >> For readability it would be nice to have something like this: >> update schema.table1 set column1 = '123' where id = 1000 > > -- > 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 > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > From dmorrison@example.com Fri Nov 04 16:19:26 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 60243 invoked from network); 4 Nov 2005 16:19:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 16:19:26 -0000 Received: (qmail 45698 invoked by uid 500); 4 Nov 2005 16:19:25 -0000 Delivered-To: dmorrison@example.com Received: (qmail 45681 invoked by uid 500); 4 Nov 2005 16:19:25 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 45670 invoked by uid 99); 4 Nov 2005 16:19:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:19:25 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of dmorrison@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO zproxy.gmail.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:19:18 -0800 Received: by zproxy.gmail.com with SMTP id k1so411766nzf for <dmorrison@example.com>; Fri, 04 Nov 2005 08:19:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tAqdIxwtLT46Nn5ffUDU174843Rp2RZV/ArI4lY160iwH4bgqWG7th6rXrmqFcgqve3zRGtOxT1YJNzMOQ4FQJ1u3t83nq3GtEJEtDzy7nHoLc908q1Lp21TeazdgL1uKhp4+EV8yR9oW/W44HZ7e8TL5LX4VAcNltsmzEw3phI= Received: by 83.161.120.155 with SMTP id q80mr665294nzi; Fri, 04 Nov 2005 08:19:02 -0800 (PST) Received: by 83.161.120.155 with HTTP; Fri, 4 Nov 2005 08:19:02 -0800 (PST) Message-ID: <dmorrison@example.com> Date: Fri, 4 Nov 2005 09:19:02 -0700 From: Larry Meadors <dmorrison@example.com> Reply-To: dmorrison@example.com Sender: dmorrison@example.com To: dmorrison@example.com Subject: Re: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-Reply-To: <dmorrison@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <dmorrison@example.com> <dmorrison@example.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ..and be careful that it isn't in here: select ' ' + blah from table Larry On 11/4/05, Nathan Maves <dmorrison@example.com> wrote: > I think that this would be a nice to have. You would have to do a > regular exp match to substitute one space for two or more spaces. > > Nathan > > > On Nov 4, 2005, at 4:12 AM, Steffen Legler (JIRA) wrote: > > > [ http://issues.apache.org/jira/browse/IBATIS-143? > > page=3Dcomments#action_12356767 ] > > > > Steffen Legler commented on IBATIS-143: > > --------------------------------------- > > > > I think, you don't understand the issue. Dynamic built SQL has > > nothing to do with deployment. The SQL-statements are built during > > runtime and will be shown without any removals of blanks in the > > log4j-logger. For debugging possible errors or for presenting the > > logger-messages it is more comfortable to have a sql-statements > > with only one blank and not 2 or more blanks between two words. > > > > Greetings from Hannover, > > > > Steffen > > > >> Remove blanks in SQL > >> -------------------- > >> > >> Key: IBATIS-143 > >> URL: http://issues.apache.org/jira/browse/IBATIS-143 > >> Project: iBatis for Java > >> Type: Improvement > >> Components: SQL Maps > >> Environment: all > >> Reporter: Steffen Legler > >> Priority: Minor > > > >> > >> Dynamically built SQL-Statements include a lot of blanks when > >> using conditional > >> elements like <isEqual>. The database doesn't care, but for > >> logging it would be > >> nice to have a well written sql-statement, e.g. : > >> <update id=3D"update" parameterClass=3D"paramClass"> > >> update schema.table1 set > >> <isEqual property=3D"listId" compareValue=3D"1"> > >> column1 =3D #value# > >> </isEqual> > >> <isEqual property=3D"listId" compareValue=3D"2"> > >> column2 =3D #value# > >> </isEqual> > >> where id=3D#instanceId# > >> </update> > >> > >> The result of a statement looks like this; > >> update schema.table1 set column1 =3D > >> '123' where id =3D 1000 > >> > >> For readability it would be nice to have something like this: > >> update schema.table1 set column1 =3D '123' where id =3D 1000 > > > > -- > > 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 > > - > > For more information on JIRA, see: > > http://www.atlassian.com/software/jira > > > > From dmorrison@example.com Fri Nov 04 16:28:00 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 64218 invoked from network); 4 Nov 2005 16:27:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 16:27:59 -0000 Received: (qmail 69736 invoked by uid 500); 4 Nov 2005 16:27:50 -0000 Delivered-To: dmorrison@example.com Received: (qmail 69688 invoked by uid 500); 4 Nov 2005 16:27:50 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 69660 invoked by uid 99); 4 Nov 2005 16:27:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:27:50 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [83.161.120.155] (HELO brmea-mail-3.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:27:44 -0800 Received: from fe-amer-10.sun.com ([83.161.120.155]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jA4GRS3F012776 for <dmorrison@example.com>; Fri, 4 Nov 2005 09:27:28 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <dmorrison@example.com> (original mail from dmorrison@example.com) for dmorrison@example.com; Fri, 04 Nov 2005 09:27:28 -0700 (MST) Received: from [83.161.120.155] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <dmorrison@example.com> for dmorrison@example.com; Fri, 04 Nov 2005 09:27:28 -0700 (MST) Date: Fri, 04 Nov 2005 09:29:19 -0700 From: Nathan Maves <dmorrison@example.com> Subject: Re: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-reply-to: <dmorrison@example.com> Sender: dmorrison@example.com To: dmorrison@example.com Message-id: <dmorrison@example.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <dmorrison@example.com> <dmorrison@example.com> <dmorrison@example.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N well I would say that you do it before any string substitutions ($$) are done. Do people really hard code stuff like that in their queries? On Nov 4, 2005, at 9:19 AM, Larry Meadors wrote: > ..and be careful that it isn't in here: > > select ' ' + blah from table > > Larry > > > On 11/4/05, Nathan Maves <dmorrison@example.com> wrote: >> I think that this would be a nice to have. You would have to do a >> regular exp match to substitute one space for two or more spaces. >> >> Nathan >> >> >> On Nov 4, 2005, at 4:12 AM, Steffen Legler (JIRA) wrote: >> >>> [ http://issues.apache.org/jira/browse/IBATIS-143? >>> page=comments#action_12356767 ] >>> >>> Steffen Legler commented on IBATIS-143: >>> --------------------------------------- >>> >>> I think, you don't understand the issue. Dynamic built SQL has >>> nothing to do with deployment. The SQL-statements are built during >>> runtime and will be shown without any removals of blanks in the >>> log4j-logger. For debugging possible errors or for presenting the >>> logger-messages it is more comfortable to have a sql-statements >>> with only one blank and not 2 or more blanks between two words. >>> >>> Greetings from Hannover, >>> >>> Steffen >>> >>>> Remove blanks in SQL >>>> -------------------- >>>> >>>> Key: IBATIS-143 >>>> URL: http://issues.apache.org/jira/browse/IBATIS-143 >>>> Project: iBatis for Java >>>> Type: Improvement >>>> Components: SQL Maps >>>> Environment: all >>>> Reporter: Steffen Legler >>>> Priority: Minor >>> >>>> >>>> Dynamically built SQL-Statements include a lot of blanks when >>>> using conditional >>>> elements like <isEqual>. The database doesn't care, but for >>>> logging it would be >>>> nice to have a well written sql-statement, e.g. : >>>> <update id="update" parameterClass="paramClass"> >>>> update schema.table1 set >>>> <isEqual property="listId" compareValue="1"> >>>> column1 = #value# >>>> </isEqual> >>>> <isEqual property="listId" compareValue="2"> >>>> column2 = #value# >>>> </isEqual> >>>> where id=#instanceId# >>>> </update> >>>> >>>> The result of a statement looks like this; >>>> update schema.table1 set column1 = >>>> '123' where id = 1000 >>>> >>>> For readability it would be nice to have something like this: >>>> update schema.table1 set column1 = '123' where id = 1000 >>> >>> -- >>> 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 >>> - >>> For more information on JIRA, see: >>> http://www.atlassian.com/software/jira >>> >> >> From dmorrison@example.com Fri Nov 04 16:30:12 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 65108 invoked from network); 4 Nov 2005 16:30:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Nov 2005 16:30:11 -0000 Received: (qmail 72075 invoked by uid 500); 4 Nov 2005 16:30:10 -0000 Delivered-To: dmorrison@example.com Received: (qmail 72058 invoked by uid 500); 4 Nov 2005 16:30:10 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 72045 invoked by uid 99); 4 Nov 2005 16:30:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:30:10 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of dmorrison@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO zproxy.gmail.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 08:30:04 -0800 Received: by zproxy.gmail.com with SMTP id k1so414018nzf for <dmorrison@example.com>; Fri, 04 Nov 2005 08:29:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bbF+bfZcKllu6LRTx9Me+sjE5t9Nnd/Dh5kin0N0aweq+U+2xQdLFVluNo6DDCFjKaTv0PiwabpdF4iQWuWsL4koFQnSxHCmbGV/QzlAfYy+GWxYGyhtNpY+cA28RMPVIj8qK/01I3x88MnUbL0V+rEtIDrwR6VQYEHh+pzBCbE= Received: by 83.161.120.155 with SMTP id z35mr256051nzh; Fri, 04 Nov 2005 08:29:48 -0800 (PST) Received: by 83.161.120.155 with HTTP; Fri, 4 Nov 2005 08:29:48 -0800 (PST) Message-ID: <dmorrison@example.com> Date: Fri, 4 Nov 2005 09:29:48 -0700 From: Larry Meadors <dmorrison@example.com> Reply-To: dmorrison@example.com Sender: dmorrison@example.com To: dmorrison@example.com Subject: Re: [jira] Commented: (IBATIS-143) Remove blanks in SQL In-Reply-To: <dmorrison@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <dmorrison@example.com> <dmorrison@example.com> <dmorrison@example.com> <dmorrison@example.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I'd bet good cash money on it. :) Larry On 11/4/05, Nathan Maves <dmorrison@example.com> wrote: > well I would say that you do it before any string substitutions ($$) > are done. Do people really hard code stuff like that in their queries? > > > On Nov 4, 2005, at 9:19 AM, Larry Meadors wrote: > > > ..and be careful that it isn't in here: > > > > select ' ' + blah from table > > > > Larry > > > > > > On 11/4/05, Nathan Maves <dmorrison@example.com> wrote: > >> I think that this would be a nice to have. You would have to do a > >> regular exp match to substitute one space for two or more spaces. > >> > >> Nathan > >> > >> > >> On Nov 4, 2005, at 4:12 AM, Steffen Legler (JIRA) wrote: > >> > >>> [ http://issues.apache.org/jira/browse/IBATIS-143? > >>> page=3Dcomments#action_12356767 ] > >>> > >>> Steffen Legler commented on IBATIS-143: > >>> --------------------------------------- > >>> > >>> I think, you don't understand the issue. Dynamic built SQL has > >>> nothing to do with deployment. The SQL-statements are built during > >>> runtime and will be shown without any removals of blanks in the > >>> log4j-logger. For debugging possible errors or for presenting the > >>> logger-messages it is more comfortable to have a sql-statements > >>> with only one blank and not 2 or more blanks between two words. > >>> > >>> Greetings from Hannover, > >>> > >>> Steffen > >>> > >>>> Remove blanks in SQL > >>>> -------------------- > >>>> > >>>> Key: IBATIS-143 > >>>> URL: http://issues.apache.org/jira/browse/IBATIS-143 > >>>> Project: iBatis for Java > >>>> Type: Improvement > >>>> Components: SQL Maps > >>>> Environment: all > >>>> Reporter: Steffen Legler > >>>> Priority: Minor > >>> > >>>> > >>>> Dynamically built SQL-Statements include a lot of blanks when > >>>> using conditional > >>>> elements like <isEqual>. The database doesn't care, but for > >>>> logging it would be > >>>> nice to have a well written sql-statement, e.g. : > >>>> <update id=3D"update" parameterClass=3D"paramClass"> > >>>> update schema.table1 set > >>>> <isEqual property=3D"listId" compareValue=3D"1"= > > >>>> column1 =3D #value# > >>>> </isEqual> > >>>> <isEqual property=3D"listId" compareValue=3D"2"= > > >>>> column2 =3D #value# > >>>> </isEqual> > >>>> where id=3D#instanceId# > >>>> </update> > >>>> > >>>> The result of a statement looks like this; > >>>> update schema.table1 set column1 =3D > >>>> '123' where id =3D 1000 > >>>> > >>>> For readability it would be nice to have something like this: > >>>> update schema.table1 set column1 =3D '123' where id =3D 1000 > >>> > >>> -- > >>> 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 > >>> - > >>> For more information on JIRA, see: > >>> http://www.atlassian.com/software/jira > >>> > >> > >> > > From dmorrison@example.com Sat Nov 05 01:11:42 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 77118 invoked from network); 5 Nov 2005 01:11:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Nov 2005 01:11:42 -0000 Received: (qmail 82803 invoked by uid 500); 5 Nov 2005 01:11:42 -0000 Delivered-To: dmorrison@example.com Received: (qmail 82785 invoked by uid 500); 5 Nov 2005 01:11:41 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 82774 invoked by uid 500); 5 Nov 2005 01:11:41 -0000 Delivered-To: dmorrison@example.com Received: (qmail 82770 invoked by uid 99); 5 Nov 2005 01:11:41 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 17:11:40 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id 962155C0 for <dmorrison@example.com>; Sat, 5 Nov 2005 02:11:19 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Sat, 5 Nov 2005 02:11:19 +0100 (CET) From: "Bahri Gencsoy (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Created: (IBATIS-218) 'i' character in property names, with Turkish locale Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 'i' character in property names, with Turkish locale ---------------------------------------------------- Key: IBATIS-218 URL: http://issues.apache.org/jira/browse/IBATIS-218 Project: iBatis for Java Type: Bug Components: SQL Maps Versions: 2.1.5 Environment: Doesn't matter, when Locale.getDefault() return Turkish locale Reporter: Bahri Gencsoy Priority: Blocker You can not use 'i' character in sqlmap files for the name of any property if locale is Turkish. Reproducing is easy, say Locale.setDefault(new Locale("tr")) in application initilization code and look at the values of properties containing 'i' character. The problem is about mapping the parameters to bean methods, not about retrieving bean methods. Patch is easy, in com/ibatis/sqlmap/engine/mapping/result/AutoResultMap change following line: propertyMap.put(propertyNames[i].toUpperCase(), propertyNames[i]); with: propertyMap.put(propertyNames[i].toUpperCase(java.util.Locale.ENGLISH), propertyNames[i]); -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Sat Nov 05 01:15:43 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 78146 invoked from network); 5 Nov 2005 01:15:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Nov 2005 01:15:42 -0000 Received: (qmail 85138 invoked by uid 500); 5 Nov 2005 01:15:42 -0000 Delivered-To: dmorrison@example.com Received: (qmail 85109 invoked by uid 500); 5 Nov 2005 01:15:41 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 85094 invoked by uid 500); 5 Nov 2005 01:15:41 -0000 Delivered-To: dmorrison@example.com Received: (qmail 85083 invoked by uid 99); 5 Nov 2005 01:15:41 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO ajax.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 17:15:41 -0800 Received: from ajax.apache.org (ajax.apache.org [83.161.120.155]) by ajax.apache.org (Postfix) with ESMTP id F276D5C0 for <dmorrison@example.com>; Sat, 5 Nov 2005 02:15:19 +0100 (CET) Message-ID: <dmorrison@example.com> Date: Sat, 5 Nov 2005 02:15:19 +0100 (CET) From: "Bahri Gencsoy (JIRA)" <dmorrison@example.com> To: dmorrison@example.com Subject: [jira] Updated: (IBATIS-218) 'i' character in property names, with Turkish locale In-Reply-To: <dmorrison@example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/IBATIS-218?page=all ] Bahri Gencsoy updated IBATIS-218: --------------------------------- Attachment: AutoResultMap.java Fixed file for version 2.1.5 > 'i' character in property names, with Turkish locale > ---------------------------------------------------- > > Key: IBATIS-218 > URL: http://issues.apache.org/jira/browse/IBATIS-218 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.5 > Environment: Doesn't matter, when Locale.getDefault() return Turkish locale > Reporter: Bahri Gencsoy > Priority: Blocker > Attachments: AutoResultMap.java > > You can not use 'i' character in sqlmap files for the name of any property if locale is Turkish. > Reproducing is easy, say Locale.setDefault(new Locale("tr")) in application initilization code and look at the values of properties containing 'i' character. > The problem is about mapping the parameters to bean methods, not about retrieving bean methods. > Patch is easy, in com/ibatis/sqlmap/engine/mapping/result/AutoResultMap change following line: > propertyMap.put(propertyNames[i].toUpperCase(), propertyNames[i]); > with: > propertyMap.put(propertyNames[i].toUpperCase(java.util.Locale.ENGLISH), propertyNames[i]); -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira From dmorrison@example.com Sun Nov 06 06:38:29 2005 Return-Path: <dmorrison@example.com> Delivered-To: dmorrison@example.com Received: (qmail 64450 invoked from network); 6 Nov 2005 06:38:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 6 Nov 2005 06:38:29 -0000 Received: (qmail 63132 invoked by uid 500); 6 Nov 2005 06:38:28 -0000 Delivered-To: dmorrison@example.com Received: (qmail 62863 invoked by uid 500); 6 Nov 2005 06:38:27 -0000 Mailing-List: contact dmorrison@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:dmorrison@example.com> List-Unsubscribe: <mailto:dmorrison@example.com> List-Post: <mailto:dmorrison@example.com> List-Id: <dev.ibatis.apache.org> Reply-To: dmorrison@example.com Delivered-To: mailing list dmorrison@example.com Received: (qmail 62833 invoked by uid 99); 6 Nov 2005 06:38:26 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Nov 2005 22:38:26 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of dmorrison@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO xproxy.gmail.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Nov 2005 22:38:20 -0800 Received: by xproxy.gmail.com with SMTP id i26so167544wxd for <dmorrison@example.com>; Sat, 05 Nov 2005 22:38:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ozXMFGalUvMt2ycnJ2U9K1yU7jWAQ/uPZSZOXiQUKKsWJPhETVFJaeV1kpBja5l5U0Zlbg8w4RPkaySgK9HsWlBuSAaLEkXmuq1lquPlW6fs4mybXQtfg6STjgfjJfq5Be4oxs1UxKk4KZ4yzLozzIqvrvlwHddgF43MrJ9SYqA= Received: by 83.161.120.155 with SMTP id l16mr4009017qbr; Sat, 05 Nov 2005 22:38:05 -0800 (PST) Received: by 83.161.120.155 with HTTP; Sat, 5 Nov 2005 22:38:05 -0800 (PST) Message-ID: <dmorrison@example.com> Date: Sat, 5 Nov 2005 23:38:05 -0700 From: Clinton Begin <dmorrison@example.com> To: dmorrison@example.com, dmorrison@example.com Subject: [VOTE] Discontinue Support for: iBATIS Java 1.x, JDK 1.3 and dmorrison@example.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25675_12115480.1131259085037" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_25675_12115480.1131259085037 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone: =3D=3D What? =3D=3D I'm going to raise a vote and recommend to discontinue support for: * iBATIS 1.x (including 2.0 compat package) * All JDKs 1.3 and earlier (and therefore old JDBC versions) * DTDs hosted by iBATIS.com =3D=3D Why? =3D=3D I'm basing my recommendations on the following facts: Only 3% of iBATIS users use iBATIS 1.x. Only 13% of iBATIS users use JDK 1.3.1 or earlier We serve up 1.4 million copies of our DTD every month from ibatis.com....which is costing me money. :-) Discontinuing support for these will allow us to move forward with more new features and lighten the code up a bit. =3D=3D When? =3D=3D iBATIS 1.x support ends as of version 2.2.0 (next feature release) JDK 1.3 and earlier versions support ends as of version 2.2.0 (next feature release) DTDs dmorrison@example.com removed by November 30th 2005 as per the warning[1] that went out in September (90 days notice). To be proactive, pragmatic and practical, we will tag the SVN repository at version 2.1.6 (next bug fix release). This version can then be branched if necessary to fix any critical issues for those living in Bedrock. =3D=3D Who? =3D=3D Would all PMC members please vote on the three items individually ( ) iBATIS 1.x is unsupported as of version 2.2.0 ( ) JDK 1.3 and earlier are unsupported as of version 2.2.0 ( ) DTDs dmorrison@example.com are removed as of November 30th, 2005. Everyone else is free to comment. If you think your business will be significantly impacted by this, please let us know. Cheers, Clinton [1] http://dmorrison@example.com/msg01333.html ------=_Part_25675_12115480.1131259085037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone:<br> <br> <span style=3D"font-weight: bold;"><span style=3D"font-weight: bold;">=3D= =3D </span>What? =3D=3D</span><br> <br> I'm going to raise a vote and recommend to discontinue support for:<br> <br> &nbsp; * iBATIS 1.x (including 2.0 compat package)<br> &nbsp; * All JDKs 1.3 and earlier (and therefore old JDBC versions)<br> &nbsp; * DTDs hosted by iBATIS.com<br> <br> <span style=3D"font-weight: bold;">=3D=3D Why? =3D=3D</span><br> <br> I'm basing my recommendations on the following facts:<br> <br> Only 3% of iBATIS users use iBATIS 1.x.<br> Only 13% of iBATIS users use JDK 1.3.1 or earlier <br> We serve up 1.4 million copies of our DTD every month from ibatis.com....wh= ich is costing me money. :-)<br> <br> Discontinuing support for these will allow us to move forward with more new= features and lighten the code up a bit.<br> <br> <span style=3D"font-weight: bold;">=3D=3D When? =3D=3D</span><br> <br> iBATIS 1.x support ends as of <span style=3D"font-weight: bold;">version 2.= 2.0</span> (next feature release)<br> JDK 1.3 and earlier versions support ends as of <span style=3D"font-weight:= bold;">version 2.2.0</span> (next feature release)<br> DTDs dmorrison@example.com removed by <span style=3D"font-weight: bold;">Nov= ember 30th 2005</span> as per the warning[1] that went out in September (90= days notice).<br> <br> To be proactive, pragmatic and practical, we will tag the SVN repository at version 2.1.6 (next bug fix release).&nbsp; This version can then be branched if necessary to fix any critical issues for those living in Bedrock.&nbsp; <br> <br> <span style=3D"font-weight: bold;">=3D=3D Who? =3D=3D</span><br> <br> Would all PMC members please vote on the three items individually<br> <br> (&nbsp; )&nbsp; iBATIS 1.x is unsupported as of version 2.2.0<br> (&nbsp; )&nbsp; JDK 1.3 and earlier are unsupported as of version 2.2.0<br= > (&nbsp; )&nbsp; DTDs dmorrison@example.com are removed as of November 30th, = 2005.<br> <br> Everyone else is free to comment.&nbsp; If you think your business will be = significantly impacted by this, please
{'source': 'Apache Software Foundation Public Mail Archives'}