Urgent and not so urgent info
2 points of observation below: - The documentation that we link to on the ibatis.apache.org website is not current. Actually, it is quite old. I would fix this myself, but, I'm not aware of the process of getting it where it needs to be and whether we are still using sourceforge to distribute the documentation. - Bugs are still using the [EMAIL PROTECTED] Shouldn't they be using the [EMAIL PROTECTED] L8r dudes... Brandon
IBM's use of iBatis for Java
All,so we at IBM and more specifically Lotus would like to use iBatis for Java's data mapper capabilities in a future release of an IBM / Lotus collaboration product. We, the developers, are excited about this and during our preliminary usage it has worked extremely well for us. However in order to do this our lawyers need to be satisfied that iBatis follows the Apache contribution procedures. I can't currently figure this out from the website. The key question I need answered is whether each contributor signs a Contributor License Agreement? Is there anywhere that this is documented on the website or can anyone help me answer this question. Many many thanks,Robert Yates
Re: IBM's use of iBatis for Java
Hi Robert, Yes, every Committer on this list signed a CLA. http://ibatis.apache.org/team.html Cheers, Clinton On 2/7/06, rob yates [EMAIL PROTECTED] wrote: All,so we at IBM and more specifically Lotus would like to use iBatis for Java's data mapper capabilities in a future release of an IBM / Lotus collaboration product. We, the developers, are excited about this and during our preliminary usage it has worked extremely well for us. However in order to do this our lawyers need to be satisfied that iBatis follows the Apache contribution procedures. I can't currently figure this out from the website. The key question I need answered is whether each contributor signs a Contributor License Agreement? Is there anywhere that this is documented on the website or can anyone help me answer this question. Many many thanks,Robert Yates
Re: IBM's use of iBatis for Java
And to add further comfort, we are very careful when accepting code contributions and patches from non-committers. We either don't use it, or the contributor must file a CLA. Cheers, Clinton On 2/7/06, Ted Husted [EMAIL PROTECTED] wrote: As Clinton says, all the committers have CLAs on file.Speaking as an ASF Member, I can assure you that following thecontributions procedures is *not* optional for an ASF project. If wedon't file a CLA, we don't get an account. Period. No exceptions. -Ted.On 2/7/06, Clinton Begin [EMAIL PROTECTED] wrote: Hi Robert,Yes, every Committer on this list signed a CLA. http://ibatis.apache.org/team.htmlCheers,Clinton On 2/7/06, rob yates [EMAIL PROTECTED] wrote: All, so we at IBM and more specifically Lotus would like to use iBatis for Java's data mapper capabilities in a future release of an IBM / Lotus collaboration product.We, the developers, are excited about this and during our preliminary usage it has worked extremely well for us.However in order to do this our lawyers need to be satisfied that iBatis follows the Apache contribution procedures.I can't currently figure this out from the website.The key question I need answered is whether each contributor signs a Contributor License Agreement? Is there anywhere that this is documented on the website or can anyone help me answer this question. Many many thanks, Robert Yates --HTH, Ted.** http://www.husted.com/ted/blog/
[jira] Commented: (IBATIS-53) Support for oracle cursors as resultsets
[
http://issues.apache.org/jira/browse/IBATIS-53?page=comments#action_12365453 ]
Michael Fagan commented on IBATIS-53:
-
A sample solution for this issue can be find at:
http://opensource2.atlassian.com/confluence/oss/display/IBATIS/Oracle+REF+CURSOR+Solutions
The modified IBATIS jars are listed as attachments.
Support for oracle cursors as resultsets
Key: IBATIS-53
URL: http://issues.apache.org/jira/browse/IBATIS-53
Project: iBatis for Java
Type: New Feature
Components: SQL Maps
Reporter: Ken Katsma
Priority: Minor
Fix For: 2.1.0
Attachments: SqlExecutor.java, SqlExecutor.java, SqlExecutor.java,
SqlExecutor.java, showcase.txt, showcase_storedprocedure.txt,
showcase_storedprocedure1.txt
iBatis doesn't currently support result sets from functions in Oracle. A
modification to SQLExecutor as detailed below can add the necessary support.
However, it requires a hard-coded check for an Oracle driver. A better
option would be to supply a factory for alternate SQLExecutor's for different
dialects. This would allow for any future database specific customization as
well.
The code change is in SQLExecutor.executeQueryProcedure (see comments):
public void executeQueryProcedure(RequestScope request, Connection conn,
String sql, Object[] parameters,
int skipResults, int maxResults,
RowHandlerCallback callback)
throws SQLException {
ErrorContext errorContext = request.getErrorContext();
errorContext.setActivity(executing query procedure);
errorContext.setObjectId(sql);
CallableStatement cs = null;
ResultSet rs = null;
try {
errorContext.setMoreInfo(Check the SQL Statement (preparation
failed).);
cs = conn.prepareCall(sql);
ParameterMap parameterMap = request.getParameterMap();
ParameterMapping[] mappings = parameterMap.getParameterMappings();
errorContext.setMoreInfo(Check the output parameters (register output
parameters failed).);
registerOutputParameters(cs, mappings);
errorContext.setMoreInfo(Check the parameters (set parameters
failed).);
parameterMap.setParameters(request, cs, parameters);
errorContext.setMoreInfo(Check the statement (update procedure
failed).);
//
// Code changes below
//
if
(conn.getMetaData().getDatabaseProductName().equalsIgnoreCase(Oracle))
{
// If in oracle then execute instead of executeQuery
boolean b = cs.execute();
errorContext.setMoreInfo(In Oracle query mode.);
errorContext.setMoreInfo(Check the output parameters (retrieval of
output parameters failed).);
// Get the output parameters first, instead of last
retrieveOutputParameters(cs, mappings, parameters);
// Then find the resultset and handle it
for (int i=0;iparameters.length;i++)
{
if (parameters[i] instanceof ResultSet)
{
rs = (ResultSet) parameters[i];
break;
}
}
errorContext.setMoreInfo(Check the results (failed to retrieve
results).);
handleResults(request, rs, skipResults, maxResults, callback);
}
//
// Non-oracle..original code
else
{
errorContext.setMoreInfo(In non-Oracle mode.);
rs = cs.executeQuery();
errorContext.setMoreInfo(Check the results (failed to retrieve
results).);
handleResults(request, rs, skipResults, maxResults, callback);
errorContext.setMoreInfo(Check the output parameters (retrieval of
output parameters failed).);
retrieveOutputParameters(cs, mappings, parameters);
}
} finally {
try {
closeResultSet(rs);
} finally {
closeStatement(cs);
}
}
An example mapping looks like:
parameterMap id=clientParameters class=map
parameter property=result jdbcType=ORACLECURSOR mode=OUT/
parameter property=maxRows jdbcType=VARCHAR
javaType=java.lang.String mode=IN/
/parameterMap
procedure id=getClientListProc resultMap=clientResult
parameterMap=clientParameters
{?= call abc.CLIENT_VIEW_PKG.client_result_list_f(?)}
/procedure
--
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: Urgent and not so urgent info
The documentation exists in SVN as an Open Office document. For some reason it has not been converted to PDF and posted. http://svn.apache.org/repos/asf/ibatis/trunk/java/docs/iBATIS-SqlMaps-2.sxw Brandon On 2/7/06, VanderArk, Richard [EMAIL PROTECTED] wrote: Is there more up to date documentation? Are you now working on that (since you have great authoring experience..). Ric -Original Message- From: Brandon Goodin [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 7:40 AM To: dev@ibatis.apache.org Subject: Urgent and not so urgent info 2 points of observation below: - The documentation that we link to on the ibatis.apache.org website is not current. Actually, it is quite old. I would fix this myself, but, I'm not aware of the process of getting it where it needs to be and whether we are still using sourceforge to distribute the documentation. - Bugs are still using the [EMAIL PROTECTED] Shouldn't they be using the [EMAIL PROTECTED] L8r dudes... Brandon
ignore case on type aliases?
I was thinking about updating the TypeHandlerFactory to ignore the case of a type alias. Is anyone opposed to this idea. This way both String and string would map to java.lang.String. I can not think of any reason why this would be a bad idea. Nathan
Re: Urgent and not so urgent info
On this same note... When are we going to start hosting the binaries and documentation on apache and get off the dreadful SF site? Nathan On Feb 7, 2006, at 7:40 AM, Brandon Goodin wrote: 2 points of observation below: - The documentation that we link to on the ibatis.apache.org website is not current. Actually, it is quite old. I would fix this myself, but, I'm not aware of the process of getting it where it needs to be and whether we are still using sourceforge to distribute the documentation. - Bugs are still using the [EMAIL PROTECTED] Shouldn't they be using the [EMAIL PROTECTED] L8r dudes... Brandon
Re: Urgent and not so urgent info
1) Documentation: Yes it's old. I'm not sure if the OO doc in SVN is any newer...I don't think I've updated it. Maybe Richard will update it for us. 2) Hosting: Yes, we should move all of our downloadables to Apache. It's both easier to deploy, and easier to download. 3) JIRA: I'll look into changing the address to use dev@ Cheers, Clinton On 2/7/06, Nathan Maves [EMAIL PROTECTED] wrote: On this same note...When are we going to start hosting the binaries and documentation onapache and get off the dreadful SF site?NathanOn Feb 7, 2006, at 7:40 AM, Brandon Goodin wrote: 2 points of observation below: - The documentation that we link to on the ibatis.apache.org website is not current. Actually, it is quite old. I would fix this myself, but, I'm not aware of the process of getting it where it needs to be and whether we are still using sourceforge to distribute the documentation. - Bugs are still using the ibatis-dev@incubator.apache.org. Shouldn't they be using the dev@ibatis.apache.org? L8r dudes... Brandon
Re: Urgent and not so urgent info
I made changes to the SVN documentation a while back. I added docs for new features that have been added. I thought we released the docs with each release of the API. Anyway, just so ya know that there have been updates made to the SVN docs. Brandon On 2/7/06, Clinton Begin [EMAIL PROTECTED] wrote: Okay, 3) I've updated the email address in JIRA. 2) I've moved all of the Java downloads to Apache. 1) No, I have not written any more docs. ;-) Cheers, Clinton On 2/7/06, Clinton Begin [EMAIL PROTECTED] wrote: 1) Documentation: Yes it's old. I'm not sure if the OO doc in SVN is any newer...I don't think I've updated it. Maybe Richard will update it for us. 2) Hosting: Yes, we should move all of our downloadables to Apache. It's both easier to deploy, and easier to download. 3) JIRA: I'll look into changing the address to use dev@ Cheers, Clinton On 2/7/06, Nathan Maves [EMAIL PROTECTED] wrote: On this same note... When are we going to start hosting the binaries and documentation on apache and get off the dreadful SF site? Nathan On Feb 7, 2006, at 7:40 AM, Brandon Goodin wrote: 2 points of observation below: - The documentation that we link to on the ibatis.apache.org website is not current. Actually, it is quite old. I would fix this myself, but, I'm not aware of the process of getting it where it needs to be and whether we are still using sourceforge to distribute the documentation. - Bugs are still using the [EMAIL PROTECTED] Shouldn't they be using the [EMAIL PROTECTED] L8r dudes... Brandon
Re: ignore case on type aliases?
I like that idea VERY MUCH. Its one of those things that I always get annoyed at but never think to change. :) Brandon On 2/7/06, Nathan Maves [EMAIL PROTECTED] wrote: I was thinking about updating the TypeHandlerFactory to ignore the case of a type alias. Is anyone opposed to this idea. This way both String and string would map to java.lang.String. I can not think of any reason why this would be a bad idea. Nathan
Re: ignore case on type aliases?
Cool I will take care of it and make it my first commit. That way I can really say that I work on an apache product :) On Feb 7, 2006, at 7:28 PM, Brandon Goodin wrote: I like that idea VERY MUCH. Its one of those things that I always get annoyed at but never think to change. :) Brandon On 2/7/06, Nathan Maves [EMAIL PROTECTED] wrote: I was thinking about updating the TypeHandlerFactory to ignore the case of a type alias. Is anyone opposed to this idea. This way both String and string would map to java.lang.String. I can not think of any reason why this would be a bad idea. Nathan
Re: Urgent and not so urgent info
On 2/7/06, Clinton Begin [EMAIL PROTECTED] wrote: 1) Documentation: Yes it's old. I'm not sure if the OO doc in SVN is any newer...I don't think I've updated it. Maybe Richard will update it for us. I was thinking the same thing...c'mon Ric, step up the plate. ;-) Larry
