[jira] Created: (IBATIS-375) Provide a way for not creating items from nested ResultMaps when the items contain only null values
Provide a way for not creating items from nested ResultMaps when the items contain only null values --- Key: IBATIS-375 URL: http://issues.apache.org/jira/browse/IBATIS-375 Project: iBatis for Java Issue Type: Improvement Components: SQL Maps Affects Versions: 2.2.0 Reporter: Stefan Langer Taken the following resultmaps (uneeded parts are left out) for a simple domainmodel where notebook contains 0 or more pages. resultMap class=notebook groupBy=id id=notebookResult result column=NB_ID jdbcType=VARCHAR property=id/ result javaType=java.util.List property=pages resultMap=Note.pageResult/ /resultMap resultMap class=page groupBy=id id=pageResult result column=P_ID jdbcType=VARCHAR property=id/ /resultMap and the following select statement: select id=selectNotebook parameterClass=java.lang.String resultMap=notebookResult SELECT nb.id as nb_id, p.id as p_id, FROM notebook nb LEFT JOIN page p ON nb.id = p.notebook_id WHERE nb.id = #id# /select Do to the left join this query will always result in at least one page being created even though the pages are actually empty. It would be nice if the mapping framework could somehow not create these empty objects. The following suggestions come to mind: Either do not create objects where all parameters are null (this indicates the left or right join scenario) or provide a way to tag a property in the resultMap which may not be null in order for the object to be created. Example: resultMap class=page groupBy=id id=pageResult result column=P_ID jdbcType=VARCHAR property=id doNotCreateOnNull=true/ /resultMap This would greatly ease the use of complex mappings where one wants to prevent the dreaded N+1 Select Problem. -- 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
[jira] Closed: (IBATIS-337) Add documentation item to left nav in Get help section to improve usability of the webpage
[ http://issues.apache.org/jira/browse/IBATIS-337?page=all ] Jeff Butler closed IBATIS-337. -- Resolution: Fixed Assignee: Jeff Butler In SVN. Will be in the next refresh of the site. Add documentation item to left nav in Get help section to improve usability of the webpage -- Key: IBATIS-337 URL: http://issues.apache.org/jira/browse/IBATIS-337 Project: iBatis for Java Issue Type: Improvement Components: Documentation Reporter: Torsten Michelmann Assigned To: Jeff Butler Priority: Trivial To find the documentation easier I suggest to add a link to a new page http://ibatis.apache.org/documentation.html in the Get help section of the left navigation. The section would then look like - How to get help +Documentation - Wiki - FAQ - Mailing Lists - Issue Tracker This page (/documentation.html) contains just a link list to to the current locations (eg. for the iBatis Java there would be a link to http://ibatis.apache.org/javadownloads.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
Re: Status of 2.3 Release
We discussed this some weeks ago. IIRC, Clinton wanted to do a new release rather than voting for GA on 2.2. Jeff Butler On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some time and contains several bug fixes over 2.1.7. I would also say that 2.2.0 could be made GA. The other thought is that there is no guarantee that 2.3 will be GA quality after we get it out there for 2 weeks, however unlikely that may be. Thanks for getting this all together! B On 11/30/06, Jeff Butler [EMAIL PROTECTED] wrote: Hi All, I have everything built for 2.3, and have everything signed and checksummed. Unfortunately, there are permission problems in the .../dist directories, so I'm stuck right now. I've sent a note to infra@ and as soon as they get the permission problems resolved, then I'll be able to publish the release. This will be the first iBATIS/Java release that uses the Apache mirroring structure - I'm going to implement the new Apache release policy according to the notice the committers received a couple of weeks ago. My release plan looks like this: 1. Post the 2.3 and 2.1.7 builds to the mirrors. 2.3 will superceed 2.2, so no need to post it 2. Label 2.3 as beta, 2.1.7 is still the GA release 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted I'll keep you posted - hopefully I'll get it done tomorrow. Jeff Butler
Re: iBATIS for Java 2.3.0 Released!
You might need to select a different mirror. I know the files have been propogated to some of the mirrors, but not all. You could also use the backup mirrors at the end of the list. Jeff Butler On 12/1/06, Tom Duffey [EMAIL PROTECTED] wrote: On Dec 1, 2006, at 11:20 AM, Jeff Butler wrote: You can obtain the new release here: http://ibatis.apache.org/javadownloads.cgi Hate to crash your party but the download link doesn't work :) Tom
iBATIS for Java 2.3.0 Released!
iBATIS for Java version 2.3.0 is now available. This release includes several bug fixes and enhancements. Additionally, this release offers new support for local caching of prepared statements. Caching prepared statements can lead to significant performance improvements in many environments. The Java DAO framework has been deprecated and removed from iBATIS as of release 2.3.0. We heartily recommend that you consider using the Spring Framework http://www.springframework.org/ for all your DAO needs! Spring offers great support for iBATIS. The paginated list methods have been deprecated with this release. The methods were confusing to many users and often misused. We suggest using native database support for paging, or that you use the query methods with skip and max settings. Release 2.3.0 supercedes the 2.2.0 release which will remain at beta status due to minor bugs. We recommend that all 2.2.0 users upgrade to version 2.3.0. I expect that there will be a vote to promote 2.3.0 to General Availability status in two weeks. You can obtain the new release here: http://ibatis.apache.org/javadownloads.cgi Enjoy! Jeff Butler
Re: iBATIS for Java 2.3.0 Released!
Nice job Jeff. This also marks the first time someone else has done the full build and deploy cycle of iBATIS. This is a milestone that shows iBATIS is truly a team effort (i.e. bus factor 1 ;-) Great job to the whole team on another successful release. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: iBATIS for Java version 2.3.0 is now available. This release includes several bug fixes and enhancements. Additionally, this release offers new support for local caching of prepared statements. Caching prepared statements can lead to significant performance improvements in many environments. The Java DAO framework has been deprecated and removed from iBATIS as of release 2.3.0. We heartily recommend that you consider using the Spring Framework http://www.springframework.org/ for all your DAO needs! Spring offers great support for iBATIS. The paginated list methods have been deprecated with this release. The methods were confusing to many users and often misused. We suggest using native database support for paging, or that you use the query methods with skip and max settings. Release 2.3.0 supercedes the 2.2.0 release which will remain at beta status due to minor bugs. We recommend that all 2.2.0 users upgrade to version 2.3.0. I expect that there will be a vote to promote 2.3.0 to General Availability status in two weeks. You can obtain the new release here: http://ibatis.apache.org/javadownloads.cgi Enjoy! Jeff Butler
Re: Status of 2.3 Release
To clarify, what I suggested a week or so ago was: We can vote for GA anytime, even after another release makes it to GA. The beta, alpha, GA status is always flexible. We could vote for GA on 2.2. right now actually. So a little closer to what Brandon is suggesting. However, I'm more interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to GA. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: We discussed this some weeks ago. IIRC, Clinton wanted to do a new release rather than voting for GA on 2.2. Jeff Butler On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some time and contains several bug fixes over 2.1.7. I would also say that 2.2.0 could be made GA. The other thought is that there is no guarantee that 2.3 will be GA quality after we get it out there for 2 weeks, however unlikely that may be. Thanks for getting this all together! B On 11/30/06, Jeff Butler [EMAIL PROTECTED] wrote: Hi All, I have everything built for 2.3, and have everything signed and checksummed. Unfortunately, there are permission problems in the .../dist directories, so I'm stuck right now. I've sent a note to infra@ and as soon as they get the permission problems resolved, then I'll be able to publish the release. This will be the first iBATIS/Java release that uses the Apache mirroring structure - I'm going to implement the new Apache release policy according to the notice the committers received a couple of weeks ago. My release plan looks like this: 1. Post the 2.3 and 2.1.7 builds to the mirrors. 2.3 will superceed 2.2, so no need to post it 2. Label 2.3 as beta, 2.1.7 is still the GA release 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted I'll keep you posted - hopefully I'll get it done tomorrow. Jeff Butler
Re: Status of 2.3 Release
My vote is to leave it the way it is. My conservative, pragmatic and adventurous sides are all satisfied by having a single GA release as well as the latest Beta release available for download. 2.2 is available in the past releases if people want it. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: I forgot about that conversation, I was thinking of this one: http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html A great example of selective memory on my part :) Anyway I'm open to a GA vote for 2.2 if we need to. But maybe we should let the dust settle on 2.3 for a few days. If it looks like it will fly, then we could do the 2.3 GA vote a little sooner. The major thing in 2.3was prepared statement caching and I know there's already been some public testing of it. Most of the fixes I did were for esoteric issues. I think 2.3 is pretty solid. Your thoughts - should I post the 2.2 build to the mirrors? That wouldn't take much effort now that I know how to sign releases (it was a strange trip into command line hacker heaven). Jeff Butler On 12/1/06, Clinton Begin [EMAIL PROTECTED] wrote: To clarify, what I suggested a week or so ago was: We can vote for GA anytime, even after another release makes it to GA. The beta, alpha, GA status is always flexible. We could vote for GA on 2.2. right now actually. So a little closer to what Brandon is suggesting. However, I'm more interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to GA. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: We discussed this some weeks ago. IIRC, Clinton wanted to do a new release rather than voting for GA on 2.2. Jeff Butler On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some time and contains several bug fixes over 2.1.7. I would also say that 2.2.0 could be made GA. The other thought is that there is no guarantee that 2.3 will be GA quality after we get it out there for 2 weeks, however unlikely that may be. Thanks for getting this all together! B On 11/30/06, Jeff Butler [EMAIL PROTECTED] wrote: Hi All, I have everything built for 2.3, and have everything signed and checksummed. Unfortunately, there are permission problems in the .../dist directories, so I'm stuck right now. I've sent a note to infra@ and as soon as they get the permission problems resolved, then I'll be able to publish the release. This will be the first iBATIS/Java release that uses the Apache mirroring structure - I'm going to implement the new Apache release policy according to the notice the committers received a couple of weeks ago. My release plan looks like this: 1. Post the 2.3 and 2.1.7 builds to the mirrors. 2.3 will superceed 2.2, so no need to post it 2. Label 2.3 as beta, 2.1.7 is still the GA release 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted I'll keep you posted - hopefully I'll get it done tomorrow. Jeff Butler
Re: Status of 2.3 Release
I'm fine with pushing 2.3. But, I had a conversation on the list with someone who feared upgrading to 2.2 because it wasn't GA. This was, apparently, a company policy. They need a feature that is available in 2.2but will not upgrade because it is not GA. If we do not make 2.2 GA then their company policy will continue to hold them up. I guess I don't see a reason why we wouldn't make it GA. It has been available for some time with fewer bugs than 2.1.7. If I were to blow off any release I'd blow off 2.1.7 because it conatins more bugs than 2.2. Brandon On 12/1/06, Clinton Begin [EMAIL PROTECTED] wrote: My vote is to leave it the way it is. My conservative, pragmatic and adventurous sides are all satisfied by having a single GA release as well as the latest Beta release available for download. 2.2 is available in the past releases if people want it. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: I forgot about that conversation, I was thinking of this one: http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html A great example of selective memory on my part :) Anyway I'm open to a GA vote for 2.2 if we need to. But maybe we should let the dust settle on 2.3 for a few days. If it looks like it will fly, then we could do the 2.3 GA vote a little sooner. The major thing in 2.3 was prepared statement caching and I know there's already been some public testing of it. Most of the fixes I did were for esoteric issues. I think 2.3 is pretty solid. Your thoughts - should I post the 2.2 build to the mirrors? That wouldn't take much effort now that I know how to sign releases (it was a strange trip into command line hacker heaven). Jeff Butler On 12/1/06, Clinton Begin [EMAIL PROTECTED] wrote: To clarify, what I suggested a week or so ago was: We can vote for GA anytime, even after another release makes it to GA. The beta, alpha, GA status is always flexible. We could vote for GA on 2.2. right now actually. So a little closer to what Brandon is suggesting. However, I'm more interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to GA. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: We discussed this some weeks ago. IIRC, Clinton wanted to do a new release rather than voting for GA on 2.2. Jeff Butler On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some time and contains several bug fixes over 2.1.7. I would also say that 2.2.0 could be made GA. The other thought is that there is no guarantee that 2.3 will be GA quality after we get it out there for 2 weeks, however unlikely that may be. Thanks for getting this all together! B On 11/30/06, Jeff Butler [EMAIL PROTECTED] wrote: Hi All, I have everything built for 2.3, and have everything signed and checksummed. Unfortunately, there are permission problems in the .../dist directories, so I'm stuck right now. I've sent a note to infra@ and as soon as they get the permission problems resolved, then I'll be able to publish the release. This will be the first iBATIS/Java release that uses the Apache mirroring structure - I'm going to implement the new Apache release policy according to the notice the committers received a couple of weeks ago. My release plan looks like this: 1. Post the 2.3 and 2.1.7 builds to the mirrors. 2.3 will superceed 2.2, so no need to post it 2. Label 2.3 as beta, 2.1.7 is still the GA release 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted I'll keep you posted - hopefully I'll get it done tomorrow. Jeff Butler
Re: Status of 2.3 Release
That's a great point. I've had similar discussions. How about this: Let's do the vote for 2.2. GA right now. Assuming it passes (I don't see why not considering how long it's been out), we update 2.1.7 to 2.2 on the website by Monday. Then, next Friday (7 days) we start the vote for 2.3 GA and give it 7 more days to settle. Within two weeks we'll have a 2.2 and a 2.3 GA. I agree that we should probably GA 2.2 because people are already using it, but also because it's the last DAO release...that way we have a GA'd final DAO. Sound good? Clinton On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: I'm fine with pushing 2.3. But, I had a conversation on the list with someone who feared upgrading to 2.2 because it wasn't GA. This was, apparently, a company policy. They need a feature that is available in 2.2but will not upgrade because it is not GA. If we do not make 2.2 GA then their company policy will continue to hold them up. I guess I don't see a reason why we wouldn't make it GA. It has been available for some time with fewer bugs than 2.1.7. If I were to blow off any release I'd blow off 2.1.7 because it conatins more bugs than 2.2. Brandon On 12/1/06, Clinton Begin [EMAIL PROTECTED] wrote: My vote is to leave it the way it is. My conservative, pragmatic and adventurous sides are all satisfied by having a single GA release as well as the latest Beta release available for download. 2.2 is available in the past releases if people want it. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: I forgot about that conversation, I was thinking of this one: http://www.mail-archive.com/dev@ibatis.apache.org/msg01855.html A great example of selective memory on my part :) Anyway I'm open to a GA vote for 2.2 if we need to. But maybe we should let the dust settle on 2.3 for a few days. If it looks like it will fly, then we could do the 2.3 GA vote a little sooner. The major thing in 2.3 was prepared statement caching and I know there's already been some public testing of it. Most of the fixes I did were for esoteric issues. I think 2.3 is pretty solid. Your thoughts - should I post the 2.2 build to the mirrors? That wouldn't take much effort now that I know how to sign releases (it was a strange trip into command line hacker heaven). Jeff Butler On 12/1/06, Clinton Begin [EMAIL PROTECTED] wrote: To clarify, what I suggested a week or so ago was: We can vote for GA anytime, even after another release makes it to GA. The beta, alpha, GA status is always flexible. We could vote for GA on 2.2. right now actually. So a little closer to what Brandon is suggesting. However, I'm more interested in leaving 2.1.7 and 2.2 in the past and getting 2.3 to GA. Cheers, Clinton On 12/1/06, Jeff Butler [EMAIL PROTECTED] wrote: We discussed this some weeks ago. IIRC, Clinton wanted to do a new release rather than voting for GA on 2.2. Jeff Butler On 12/1/06, Brandon Goodin [EMAIL PROTECTED] wrote: Curious why we are superceding 2.2 wit 2.3? 2.2 has been available for some time and contains several bug fixes over 2.1.7. I would also say that 2.2.0 could be made GA. The other thought is that there is no guarantee that 2.3 will be GA quality after we get it out there for 2 weeks, however unlikely that may be. Thanks for getting this all together! B On 11/30/06, Jeff Butler [EMAIL PROTECTED] wrote: Hi All, I have everything built for 2.3, and have everything signed and checksummed. Unfortunately, there are permission problems in the .../dist directories, so I'm stuck right now. I've sent a note to infra@ and as soon as they get the permission problems resolved, then I'll be able to publish the release. This will be the first iBATIS/Java release that uses the Apache mirroring structure - I'm going to implement the new Apache release policy according to the notice the committers received a couple of weeks ago. My release plan looks like this: 1. Post the 2.3 and 2.1.7 builds to the mirrors. 2.3 will superceed 2.2, so no need to post it 2. Label 2.3 as beta, 2.1.7 is still the GA release 3. Call for a vote for 2.3 GA two weeks after 2.3 is posted I'll keep you posted - hopefully I'll get it done tomorrow. Jeff Butler
