[jira] Issue Comment Edited: (IBATIS-142) JDBC 3 Generated Keys Support
[ https://issues.apache.org/jira/browse/IBATIS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602610#action_12602610 ] zavisagie edited comment on IBATIS-142 at 6/5/08 3:55 AM: - I have included the following patch: ibatis-jdbc3-patch.txt It is for adding jdbc3 support and was derived from ibatis 2.3.2. It's a real hack, since I use a statically accessed ThreadLocal to pass the generated key across layers of interfaces and is only meant for the desperate (like me). This is not intended for inclusion in ibatis, but merely to get jdbc3 generated keys working quickly and works only with jdbc3 prepareStatement( String sql, String[] columns ) setting a single column in that array. No config dtd's have been modified and it uses selectKey to pass in the column name with a prefix: selectKey keyProperty=id resultClass=java.lang.Long KEY_COLUMN: mytable_id /selectKey The type attribute is ignored. So pre or post becomes irrelevant in this scenario. It was the least intrusive way I could just get it working, and in this way will still work with abator. All standard features should still work and it passed all the unit tests. Please post any bugs in this patch here (if no one minds), until this feature is properly implemented. was (Author: zavisagie): This patch is for adding jdbc3 support and was derived from ibatis 2.3.2. It's a real hack, since I use a statically accessed ThreadLocal to pass the generated key across layers of interfaces and is only meant for the desperate (like me). This is not intended for inclusion in ibatis, but merely to get jdbc3 generated keys working quickly and works only with jdbc3 prepareStatement( String sql, String[] columns ) setting a single column in that array. No config dtd's have been modified and it uses selectKey to pass in the column name with a prefix: selectKey keyProperty=id resultClass=java.lang.Long KEY_COLUMN: mytable_id /selectKey The type attribute is ignored. So pre or post becomes irrelevant in this scenario. It was the least intrusive way I could just get it working, and in this way will still work with abator. Please post any bugs in this patch here (if no one minds), until this feature is properly implemented. JDBC 3 Generated Keys Support - Key: IBATIS-142 URL: https://issues.apache.org/jira/browse/IBATIS-142 Project: iBatis for Java Issue Type: Improvement Components: SQL Maps Reporter: Brandon Goodin Priority: Minor Attachments: 2008-03-31-inwork.patch, ibatis-jdbc3-patch.txt public int executeUpdate(String sql,int autoGeneratedKeys) public boolean execute(String sql,int autoGeneratedKeys) public ResultSet getGeneratedKeys() We should provide support for jdbc auto generated keys retrieval. This is only available in Java 1.4. So, we would have to throw an UnsupportedFeatureException if 1.3 or earlier was being used. Brandon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IBATIS-514) Wrong sqlmap file including the wrong property name cannot be found
Wrong sqlmap file including the wrong property name cannot be found --- Key: IBATIS-514 URL: https://issues.apache.org/jira/browse/IBATIS-514 Project: iBatis for Java Issue Type: Improvement Components: SQL Maps Affects Versions: 2.3.0 Reporter: Hideyuki Suzumi Wrong sqlmap file including the wrong property name cannot be found. Because message of exception doesn't contain sqlmap file name. This is fatal in a large-scale development project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IBATIS-142) JDBC 3 Generated Keys Support
[ https://issues.apache.org/jira/browse/IBATIS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602610#action_12602610 ] zavisagie edited comment on IBATIS-142 at 6/5/08 7:49 AM: - I have included the following patch: ibatis-jdbc3-patch.txt It is for adding jdbc3 support and was derived from ibatis 2.3.2. It's a real hack, since I use a statically accessed ThreadLocal to pass the generated key across layers of interfaces and is only meant for the desperate (like me). This is not intended for inclusion in ibatis, but merely to get jdbc3 generated keys working quickly and works only with jdbc3 prepareStatement( String sql, String[] columns ) setting a single column in that array. No config dtd's have been modified and it uses selectKey to pass in the column name with a prefix: selectKey keyProperty=id resultClass=java.lang.Long KEY_COLUMN: mytable_id /selectKey The type attribute is ignored. So pre or post becomes irrelevant in this scenario. It was the least intrusive way I could just get it working, and in this way will still work with abator. All standard features should still work and it passed all the unit tests. was (Author: zavisagie): I have included the following patch: ibatis-jdbc3-patch.txt It is for adding jdbc3 support and was derived from ibatis 2.3.2. It's a real hack, since I use a statically accessed ThreadLocal to pass the generated key across layers of interfaces and is only meant for the desperate (like me). This is not intended for inclusion in ibatis, but merely to get jdbc3 generated keys working quickly and works only with jdbc3 prepareStatement( String sql, String[] columns ) setting a single column in that array. No config dtd's have been modified and it uses selectKey to pass in the column name with a prefix: selectKey keyProperty=id resultClass=java.lang.Long KEY_COLUMN: mytable_id /selectKey The type attribute is ignored. So pre or post becomes irrelevant in this scenario. It was the least intrusive way I could just get it working, and in this way will still work with abator. All standard features should still work and it passed all the unit tests. Please post any bugs in this patch here (if no one minds), until this feature is properly implemented. JDBC 3 Generated Keys Support - Key: IBATIS-142 URL: https://issues.apache.org/jira/browse/IBATIS-142 Project: iBatis for Java Issue Type: Improvement Components: SQL Maps Reporter: Brandon Goodin Priority: Minor Attachments: 2008-03-31-inwork.patch, ibatis-jdbc3-patch.txt public int executeUpdate(String sql,int autoGeneratedKeys) public boolean execute(String sql,int autoGeneratedKeys) public ResultSet getGeneratedKeys() We should provide support for jdbc auto generated keys retrieval. This is only available in Java 1.4. So, we would have to throw an UnsupportedFeatureException if 1.3 or earlier was being used. Brandon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IBATIS-515) Element comments for DTDs
Element comments for DTDs - Key: IBATIS-515 URL: https://issues.apache.org/jira/browse/IBATIS-515 Project: iBatis for Java Issue Type: Improvement Components: Documentation Reporter: Benjamin Bortfeldt Priority: Minor Attachments: sql-map-2.dtd, sql-map-config-2.dtd We have created comments for the DTDs so they can be shown as tooltip in Eclipse. The comments for the elements discriminator and subMap are still missing because we could not find information about them in the documentation. We have only added comments for elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IBATIS-507) Ibator support for table defined subpackage
[
https://issues.apache.org/jira/browse/IBATIS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Butler closed IBATIS-507.
--
Resolution: Won't Fix
This seems like an unusual request to me, so I don't think we should include it
in the base ibator code. However, I have made some recent improvements to the
extensibility of ibator that will enable you to easily implement this for your
needs:
ibatorContext introspectedTableImplementation=com.foo.Bar
...
/ibatorContext
Then Java code like this:
package com.foo;
import org.apache.ibatis.ibator.internal.db.IntrospectedTableDefaultImpl;
public class Bar extends IntrospectedTableDefaultImpl {
@Override
public String getJavaModelPackage() {
...
}
@Override
public String getDAOPackage() {
...
}
@Override
public String getSqlMapPackage() {
...
}
}
Ibator support for table defined subpackage
---
Key: IBATIS-507
URL: https://issues.apache.org/jira/browse/IBATIS-507
Project: iBatis for Java
Issue Type: New Feature
Components: Tools
Affects Versions: 2.3.3
Environment: N/A
Reporter: Dan Turkenkopf
Priority: Minor
Attachments: ibator_subpackage.patch
It would be helpful to be able to specify a subpackage for any given table
when using Ibator to generate the code.
For example, I might want to put table X in com.test.foo and table Y in
com.test.bar.
I've added the property subPackage to the table definition which overrides
the schema based subpackage fragment if set.
Using the above example, I'd add property name=subPackage value=foo/ to
the defintion for table X.
Patch is attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (IBATISNET-269) Show NVelocity Dynamic SQL syntax support
[ https://issues.apache.org/jira/browse/IBATISNET-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Bayon closed IBATISNET-269. -- Resolution: Fixed In SVN It's also allowed to change the iBATIS Dynamic SQL engine via code configuration, see the property DynamicSqlEngine on ConfigurationSetting Show NVelocity Dynamic SQL syntax support - Key: IBATISNET-269 URL: https://issues.apache.org/jira/browse/IBATISNET-269 Project: iBatis for .NET Issue Type: New Feature Components: DataMapper Affects Versions: DataMapper 3.0 Reporter: Gilles Bayon Assignee: Gilles Bayon Fix For: DataMapper 3.0 Paremeters should be typeof IDictionarystring, object Samples === !-- Nvelocity dynamic source -- select id=NVelocity.Simple sqlSource=NVelocitySqlSource resultMap=account-result parameterClass=map select * from Accounts where Account_Id= $account.id /select select id=NVelocity.If sqlSource=NVelocitySqlSource resultClass=Account remapResults=true parameterClass=map SELECT Account_ID as Id, #if($account.FirstName == Joe) Account_FirstName as FirstName, #elseif($account.LastName == Dalton) Account_LastName as LastName, #end Account_Email as EmailAddress FROM Accounts where Account_Id= $account.id /select Use as usual IDictionarystring, object parameters = new Dictionarystring, object(); parameters.Add(account, paramAccount); Account account = dataMapper.QueryForObjectAccount(NVelocity.Simple, parameters); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IBATISNET-270) ParseGenericArguments IsMatch is very slow
[
https://issues.apache.org/jira/browse/IBATISNET-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Bayon closed IBATISNET-270.
--
Resolution: Fixed
Fix Version/s: DataMapper 1.6.2
Assignee: Gilles Bayon
Thanks,
Corrected also in version 3.0
In SVN
ParseGenericArguments IsMatch is very slow
--
Key: IBATISNET-270
URL: https://issues.apache.org/jira/browse/IBATISNET-270
Project: iBatis for .NET
Issue Type: Improvement
Components: DataMapper
Affects Versions: DataMapper 1.6.1
Reporter: Michael Schall
Assignee: Gilles Bayon
Fix For: DataMapper 1.6.2
Attachments: After change.jpg, Before change.jpg
I knew .* is expensive in regular expressions, but I had no idea how
expensive! In our application when ConfigureAndWatch is called, the IsMatch
function call within ParseGenericArguments is taking 5000ms (reported by
dotTrace). The method is called 1005 times at 5ms a piece. By simply
removing the .* from the beginning of the regular expression, the time is
brought down to a total of 4ms (not per call, total)! I also made the RegEx
object a static of the class so we aren't re-creating the expression for each
call to bring the total time down to 2ms! I'll attach 2 images of the
before and after traces if I can.
Please check my work... I have tested it with my app and everything works
fine.
Mike
I will include the patch here:
private readonly static Regex _generic = new Regex(@`\d*\[\[,
RegexOptions.Compiled);
private void ParseGenericArguments(string originalString)
{
// Check for match
bool isMatch = _generic.IsMatch(originalString);
if (!isMatch)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
